db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Zaun (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-2109) System privileges
Date Thu, 17 Jan 2008 06:58:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559833#action_12559833
] 

mzaun edited comment on DERBY-2109 at 1/16/08 10:57 PM:
--------------------------------------------------------------


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 M@rtin reads DatabasePrincipal "M\\@rtin".
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 "M\\@rtin"
    DatabasePrincipal "m\\@rtin"
    DatabasePrincipal "M\\@RTIN"

b) all feasible, but each denotes a different user:
    DatabasePrincipal "\"M\\@rtin\""
    DatabasePrincipal "\"m\\@rtin\""
    DatabasePrincipal "\"M\\@RTIN\""

> 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


      was (Author: mzaun):
    
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 M@rtin reads DatabasePrincipal "M\\@rtin".
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 "M\\@rtin"
    DatabasePrincipal "m\\@rtin"
    DatabasePrincipal "M\\@RTIN"

b) all feasible, but each denotes a different user:
    DatabasePrincipal "\\"M\\@rtin\\""
    DatabasePrincipal "\\"m\\@rtin\\""
    DatabasePrincipal "\\"M\\@RTIN\\""

> 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.


Mime
View raw message