[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561076#action_12561076
]
Daniel John Debrunner commented on DERBY-2109:
----------------------------------------------
Rick wrote:
> 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).
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.
In SQL this behaviour, mapping UserName to authorization identifier is defined
by the standard.
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
identifier 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 uses, 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, since 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 one 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.
> 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.
