db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3673) Add checks that a new role isn't already a user authorization id
Date Mon, 19 May 2008 16:21:58 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-3673:

    Attachment: derby-3673-2.stat

This patch, derby-3673-2, addresses one of Ricks comments (more
below), and also improves somewhat on the previous implementation, in
that this present patch, if possible, maps from the properties user
("derby.user.<user>" to canonical internal form before checking for a
match against the role, instead of trying to compute the external form
from the internal form and then look up that property.

This will work for users defined by database properties, and system properties if
specified in derby.properties. However, the new approach will not work
for JVM properties if the security manager is enabled and the
permission to execute System.getProperties is not given
(PropertyPermission("*", "read,write"),
cf. http://java.sun.com/j2se/1.5.0/docs/api/java/lang/SecurityManager.html#checkPropertiesAccess()).

In such a case we fall back on mapping in the other direction, as in
the first patch, since this only needs permission to read access
(PropertyPermission("derby.user.*", "read").

Rick, the first comment where you warn against hard-coding "User" in
the error message: I don't really have a user descriptor, so I can't
call getDescriptorType. I did modify the hard-coded "Role" in the
error message a few lines up to use rd.getDescriptorType(), though.

For the existing user case, "USER" is a SQL keyword so I am not sure
it needs be localized. But we could create a new error message to
cover this situation, which would be localized. What do you think?

Running regression tests now.

Patch details:

M      java/engine/org/apache/derby/impl/sql/execute/CreateRoleConstantAction.java

Added check against schema owners. Moved more logic over to
PropertyUtil#existsBuiltinUser to simplify code in

M      java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java

Renamed inspect* methods to visit* and added more prominent Javadocs
to indicate the drop behavior better.  Added existsSchemaOwnedBy.

M      java/engine/org/apache/derby/iapi/services/property/PropertyUtil.java

Added existsBuiltinUser and minions.

M      java/engine/org/apache/derby/iapi/util/StringUtil.java

Added normalizeSQLIdentifier and
compressQuotes. normalizeSQLIdentifier is used by minion of

M      java/engine/org/apache/derby/iapi/util/IdUtil.java

Same as previous patch.

M      java/testing/org/apache/derbyTesting/functionTests/tests/lang/RolesTest.java

New test for an additional user which would we would fail to find in
the first patch due to mapping direction. New test for existing user
found via schema owner.

M      java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj

Moved a utility method, compressQuotes, to StringUtil, since I needed
it in StringUtil#normalizeSQLIdentifier.

M      java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java
M      java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java

> Add checks that a new role isn't already a user authorization id
> ----------------------------------------------------------------
>                 Key: DERBY-3673
>                 URL: https://issues.apache.org/jira/browse/DERBY-3673
>             Project: Derby
>          Issue Type: Sub-task
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For:
>         Attachments: derby-3673-1.diff, derby-3673-1.diff, derby-3673-1.stat, derby-3673-2.diff,
> Derby current does not have dictionary information about legal users.
> Authentication is configurable as being derby internal, LDAP based, or
> user supplied.
> SQL specifies that user ids and role names go in the same namespace
> (authorization ids).  Therefore, at role creation time, a new role
> name should be checked against legal users for this database, and be
> defined if there is already a user id by that name.
> Unfortunately, since there is currently no reliable dictionary
> information about legal users, the best we can do presently is perform
> heuristic checks that a proposed role id is not already a user id.
> Since the check can not not reliable, we should also add a check to
> prohibit conncting with a user id that is a known role id.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message