[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559833#action_12559833
]
Martin Zaun commented on DERBY-2109:
------------------------------------
Hi Dan,
thanks for the pointer and your comments on the rules for User Identifiers.
> Daniel John Debrunner wrote:
> Given that the representation of user identifiers can cause confusion (see
> http://wiki.apache.org/db-derby/UserIdentifiers) it would be good if the
> DatabasePrincipal javadoc and the functional spec indicated how it (with
> examples) handles user name (in the code and the policy file).
I see: we need to document some extra rules for user names in policy files,
because
a) we're bound to the policy file syntax, i.e., the name argument to
DatabasePrincipal needs to be a Java String literal in double quotes (in
contrast to the use of identifiers in SQL) and
b) the functional spec introduces the special characters *, @, and \, which
otherwise are ordinary characters in user identifiers.
So, I agree it's of importance to document this in the javadoc, functional
spec, the above wiki page, and also as comments in server.policy and
template.policy.
I'll update my patch (javadocs, policy files) with more comments and can also
add some examples to the User Identifiers wiki page when we have agreement.
Before replying to your detailed comments, let me try to backtrack and
summarize the cases:
1) Non-delimited user identifiers:
1.1) I understand the User Identifier document as saying that identifiers are
case-INsensitive unless delimited by double-quotes.
1.2) The policy file syntax requires the argument to DatabasePrincipal to be a
Java String literal, i.e., enclosed in double-quotes.
1.3) The enclosing double-quotes imposed by the policy file syntax shouldn't
count towards the user name, since they're mandated by Java (consistent with
the examples in the User Identifiers document), e.g., DatabasePrincipal "eve"
displays a non-delimited identifier.
1.4) According to the rules, non-delimited user names in policy files may be
written all-uppper, -lower, or mixed case but are to be interpreted
case-INsensitively, e.g., DatabasePrincipal "eVe" and DatabasePrincipal "EVE"
both mean the same for authentication and authorization purposes,
1.5) The current patch does not yet perform the authorization checks for
non-delimited user names on their normal form -- but it shouldn't be too
difficult to add this once we have agreement.
2) Delimited user identifiers:
2.1) Users can form a delimited identifier in policy files by putting escaped
double-quotes into the String literal (consistent with the examples in the User
Identifiers document), e.g., DatabasePrincipal "\\"eVe\"" displays a delimited
identifier.
2.2) Those delimited user names are to be interpreted case-sensitively for
authentication and authorization purposes.
2.3) I've tested that the DERBY-2109 patch works with delimited identifiers in
policy files and authenticated user names and handles them case-sensitively.
So, all seems to be done here.
3) User identifiers with special System Privileges characters *, @, or \:
3.1) According to the functional spec, these special characters need to be
escaped when they're just part of a DatabasePrincipal user name.
3.2) By the Java syntax, the backslash character itself needs to be escaped,
e.g., a grant for user [EMAIL PROTECTED] reads DatabasePrincipal "[EMAIL
PROTECTED]".
3.3) This means that within the DERBY-2109 autherization checks, all special
characters in authenticated user names need to be escaped by \ before they're
matched against the DatabasePrincipal.
3.4) The published patch does not yet apply that escaping of special
characters, as you've rightfully pointed out, but I've successfully tested a
quick fix already (see below).
> It looks like user names would be entered in their normal form in the policy
> file unless they include one of the special characters *, \ and @.
I don't follow: What's the issue with special characters in normal forms?
For example, we should be able to support all of these:
a) all feasible, all denote the same user:
DatabasePrincipal "[EMAIL PROTECTED]"
DatabasePrincipal "[EMAIL PROTECTED]"
DatabasePrincipal "[EMAIL PROTECTED]"
b) all feasible, but each denotes a different user:
DatabasePrincipal "\\"[EMAIL PROTECTED]""
DatabasePrincipal "\\"[EMAIL PROTECTED]""
DatabasePrincipal "\\"[EMAIL PROTECTED]""
> What about if the user name includes a double quote?
Works, see 2.3) above.
> It's also worth noting that policy file and the DatabasePrincipal are using
> back-slash as an escape, thus a normalized user name of eve* would have to
> eve\\* in the policy file (I think).
Correct. Also see 3.2) above.
> A single back-slash in the user name would be four backslashes in the policy
> file.
Correct. For instance, user M\rtin would receive a policy grant as
DatabasePrincipal "M\\\\rtin"
> I think the patch has some issues with name handling:
> EmbedConnection takes the user name from the connection request and passes it
> into SecurityUtil.checkDatabaseCreatePermission.
> That method takes the name and passes it into the constructor for
> DatabasePrincipal.
> The problem is that the rules for the format of the name in DatabasePrincipal
> do not match the format of the name for connection requests, this is due to
> the special escaping that happens in DatabasePrincipal to cope with the
> special characters *, @ and \.
Good catch. I've tested a quick fix, see 3.4) above, which I'll publish soon.
The best place to perform the escaping of special System Privileges characters
is within the method
org.apache.derby.security.SecurityUtil.createDatabasePrincipalsSubject(String
user)
right before the DatabasePricipal is instantiated with the user name. That
way, the escaping is done for all authorization checks (Rick, thanks for having
suggested that small code refactorization!) and the modified user name stays
local.
Martin
> System privileges
> -----------------
>
> Key: DERBY-2109
> URL: https://issues.apache.org/jira/browse/DERBY-2109
> Project: Derby
> Issue Type: New Feature
> Components: Security
> Affects Versions: 10.3.1.4
> Reporter: Rick Hillegas
> Assignee: Martin Zaun
> Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat,
> derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat,
> DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff,
> DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat,
> DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat,
> SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html,
> systemPrivs.html, systemPrivs.html
>
>
> Add mechanisms for controlling system-level privileges in Derby. See the
> related email discussion at
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
> The 10.2 GRANT/REVOKE work was a big step forward in making Derby more
> secure in a client/server configuration. I'd like to plug more client/server
> security holes in 10.3. In particular, I'd like to focus on authorization
> issues which the ANSI spec doesn't address.
> Here are the important issues which came out of the email discussion.
> Missing privileges that are above the level of a single database:
> - Create Database
> - Shutdown all databases
> - Shutdown System
> Missing privileges specific to a particular database:
> - Shutdown that Database
> - Encrypt that database
> - Upgrade database
> - Create (in that Database) Java Plugins (currently Functions/Procedures,
> but someday Aggregates and VTIs)
> Note that 10.2 gave us GRANT/REVOKE control over the following
> database-specific issues, via granting execute privilege to system
> procedures:
> Jar Handling
> Backup Routines
> Admin Routines
> Import/Export
> Property Handling
> Check Table
> In addition, since 10.0, the privilege of connecting to a database has been
> controlled by two properties (derby.database.fullAccessUsers and
> derby.database.defaultConnectionMode) as described in the security section of
> the Developer's Guide (see
> http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
