[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560512#action_12560512
]
Rick Hillegas commented on DERBY-2109:
--------------------------------------
I would like to share some thoughts about the case-sensitivity of
DatabasePrincipals. It seems to me that there are at least three concepts of
identity in play here:
1) UserName - This is what is passed to the authentication service as part of
credentials checking.
2) AuthorizationID - This is the owner of a schema and the grantor and grantee
of fine-grained SQL privileges via the GRANT/REVOKE commands
3) DatabasePrincipal - This is the recipient of shutdown and createDatabase
privileges
UserName and AuthorizationID are not the same thing. Unfortunately, the spec
attached to this issue says that they are the same thing. That's just a mistake
and it needs to be cleaned up.
To illustrate the difference between UserNames and AuthorizationIDs, consider
the following: From the point of view of the authentication service, the
following are all distinct UserNames:
Edward
EdWard
EDWARD
"Edward"
"EdWard"
These, however, map to only 3 distinct AuthorizationIDs:
Edward = EdWard = EDWARD
"Edward"
"EdWard"
The practical consequence of this is that Edward and EdWard will authenticate
with different credentials but will be thrown into the same schema and will be
able to view and edit one another's data. That is, the following two connection
URLs authenticate with different credentials but are thrown into the same
schema and are treated by GRANT/REVOKE as the same person:
connect 'jdbc:derby:mydb;user=Edward;password=EdwardPassword';
connect 'jdbc:derby:mydb;user=EdWard;password=EdWardPassword';
Derby's solution to this problem is to tell the customer that they need to add
two new users to their authentication system: "Edward" and "EdWard" so that
Derby can disambiguate these users. This is frustrating to customers who want
to integrate Derby applications into company-wide processes which rely on a
single, organization-wide authentication scheme.
I suspect that this behavior goes back to the introduction of CREATE SCHEMA
long before Derby was open-sourced.
I think it would be unfortunate if we added yet another concept of identity. So
it makes sense to me that a DatabasePrincipal represents either a UserName or
an AuthorizationID. But which one?
AuthorizationID seems like a good fit once you are operating inside a database.
I have reservations about using it at the system-wide level where there are no
schemas or GRANT/REVOKE privileges.
I also have misgivings about the following scenario:
A) There is a system administrator with UserName Edward.
B) Many applications run in the system, including a Payroll application which
has a user named EdWard.
C) I want to grant shutdown privilege to Edward but not to EdWard.
I am wondering whether we should abandon the idea of using the policy file to
control database-specific privileges (other than createDatabase itself). This
would mean that in the future we plan to use GRANT/REVOKE extensions to manage
privileges once you are inside a database. The policy file would then only be
used for system-wide privileges where you do not have a database context. If we
went down this path, then we would get rid of the @ syntax and many of the
escaping cases which are proving to be so confusing. In this world, a
DatabasePrincipal would correspond to a system-wide UserName.
> 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.
