db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements
Date Thu, 16 Feb 2006 19:31:09 GMT
    [ http://issues.apache.org/jira/browse/DERBY-866?page=comments#action_12366665 ] 

Daniel John Debrunner commented on DERBY-866:
---------------------------------------------

Thanks for the updated spec, some comments:

- are you expecting this to be ready for the 10.2 release?

- I'm still confused by the phrase "no real ANSI SQL standard for managing users in SQL",
the "real" implies there is some sort of ANSI standard in this area, but provisional, or not
widely adopted or you imagined it. :-)

- what the defined behaviour for 'CREATE USER dan', ie. no IDENTIFIED BY clause, since it's
optional?

- Without a special type token between IDENTIFIED BY and the auto_info I think you require
that the authentication provider is defined for the database, otherwise I don't see how the
code decides to store a hash of the password or the mapping info.
I was assuming it would be

CREATE USER dan IDENTIFIED BY PASSWORD 'ek992ffdwfe'

or

CREATE USER dan IDENTIFIED BY LDAP 'djd@apache.org'

- Can user_id and auto_info be parameter markers?

- How the mapping works is not defined.

- SYSUSERS example has PASSWORD in it

- Development phasing is a strange section.  Really there is only a single phase (as described)
for the functionality described by this spec. Phases 2 and 3 are future ideas, so thye are
not related to the development of this spec. I would have put them in a separate section like
"Future Direction".

- There is a hole in the spec, if this is implemented in 10.2 and DERBY-464 (DML grant revoke)
is implemented then the addition of CREATE USER will (could?) allow anyone to create users
in the database., which in turn allows anyone to create schemas of any name. You refer to
this in your NOTE in the Syntax section, where you say CREATE USER permission will be required,
but as far as I know no-one is working on that. Ie. as you have written, what happens when
the database is in SQL authorization mode, but system priviledges are *not* available, as
I believe will be the case for 10.2?

> BUILT-IN Derby User Management (DDL) Enhancements
> -------------------------------------------------
>
>          Key: DERBY-866
>          URL: http://issues.apache.org/jira/browse/DERBY-866
>      Project: Derby
>         Type: Improvement
>   Components: Security
>     Versions: 10.2.0.0
>     Reporter: Francois Orsini
>      Fix For: 10.2.0.0
>  Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html
>
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached
to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by providing
a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be
defined at the system and/or database level. Users created at the system level can be defined
via JVM or/and Derby system properties in the derby.properties file. Built-in users created
at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY)
which sets a database property.
> Defining a user at the system level is very convenient and practical during the development
phase (EOD) of an application - However, the user's password is not encrypted and consequently
appears in clear in the derby.properties file. Hence, for an application going into production,
whether it is embedded or not, it is preferable to create users at the database level where
the password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing a more
intuitive and known interface, it will ease Built-In User management at the database level
as well as Derby's adoption.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message