[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561086#action_12561086
]
Rick Hillegas commented on DERBY-2109:
--------------------------------------
Thanks for the continued discussion, Dan. I agree that we seem to be talking
past one another.
>> 2) AuthorizationID -- this is the SQL concept of identity. This is
>> case-insensitive unless double-quoted.
>
>We seem to be using the same terms for slightly different concepts.
>
>I believe I'm using authorization identifier in the way that the SQL standard
>defines it. This would be a case-sensitive value that defines a unique
>identity in the sql system (database). Thus an authorization identifier is
>never double >quoted, contradicting your statement 2).
I think the relevant section of the SQL spec is part 2 section 5.4 (names and
identifiers). In that section <authorization identifier> can resolve to be a
<user identifier> which in turn can resolve to an <identifier> which in turn
can resolve to a <regular identifier> or a <delimited identifier>. The <regular
identifier> is uppercased to a normalized value regardless of its original
casing and the <delimited identifer> is quoted and is not uppercased. This is
what I mean by "This is case-insensitive unless double-quoted".
I think the disconnect here is that the authorization identifier can be
referenced in two ways. When it is used in a SQL statement and resolves to a
<regular identifier>, it is normalized to uppercase and so, as I would put it,
it is case-insensitive. When it is referenced in the form stored in the system
catalogs, it is case-sensitive.
>
>A UserName is a representation of an authorization identifier using the SQL
>rules for regular and delimited identifiers and thus has the case folding
>rules etc.
The term UserName is a word I invented for this discussion. But it pretty much
corresponds to userName as used in the javadoc for UserAuthenticator.
>
>In SQL this behaviour, mapping UserName to authorization identifier is defined
>by the standard.
This is where I am not tracking you. The term UserName does not occur in the
SQL standard as far as I know. It is a term which I thought I invented in order
to bring some precision to this discussion. But I don't seem to have succeeded.
Can you refer me to the section of the SQL standard which defines this term (or
a related term)? That will help me propose some new language which we can agree
on.
>
>In Java code and Java property files Derby chose to use SQL identifier rules
>(ie. UserName) as the representation of an authorization identifier. Looking
>back this maybe was a poor choice, a direct representation of the
>authorization i>dentifier might have been better, (ie. jdbc:derby:cs;user=fred
>and jdbc:derby:cs;user=FRED would connect as different authorization ids,
>today they map to the same authorization id). So if we want to be consistent
>with other Java us>es, the policy file should probably use UserName, however
>using authorization identifier might be clearer.
>
>> 1) UserName -- this is part of the credentials passed to the authentication
>> service. This could be case-sensitive or case-insensitive depending on the
>> rules of the authentication service.
>
>I think the last sentence is incorrect. The rules of UserName are set by
>Derby, not an arbitrary implementation of the authentication service.
>As above, the rules for how UserName map to a unique identity follows the
>rules of SQL identifiers, and thus UserNames of FRED and fred always map to
>the same unique identity FRED. However, I'm not sure you agree with this,
>sinc>e you are promoting authorization identifier as a SQL only concept. That
>may be a valid approach, but I think you need to clearly state the rules for
>that, and then we can discuss if having two different models (one for database
>and o>ne for system) adds any benefit or adds complication. The rules would
>need to state how UserName maps to a unique identity in a system context.
Ha! Once we can agree on some terms, I can take another crack at stating the
rules.
Thanks.
> 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.
