db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-2109) System privileges
Date Mon, 21 Jan 2008 21:21:16 GMT
Rick Hillegas (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561118#action_12561118
> Rick Hillegas commented on DERBY-2109:
> --------------------------------------
>> So I think we can agree that a user has a unique identity, can we call this UID?
This corresponds to what is stored in the system tables. 
> I'm afraid that when I read these words, they sound like this to me: "A person has a
unigue identity, a UID, which is stored in the system tables." I don't agree with this.
 > Two persons (Edward and EdWard in my example) end up with the same 
identity. The identity is not unique. That's a problem.

Does it help if I say "a *database* user has a unique database identity, 
call it DBUID)", because that's a fact of how Derby works and how the 
SQL Standard require it works. We can only be concerned about the 
identity and its uniqueness & meaning in Derby's realm, database or 
system. How a real person maps onto a Derby database or system users is 
not relevant here. E.g. Edward and EdWard defining two unique people is 
obviously unique only in some specified domain, e.g. a unix system 
logins in a corporate setup. Such a setup has to understand how 
identities need to be mapped across systems with different rules, e.g. 
mapping those unix login names to e-mail addresses would also fail with 
a simple use of login@acme.com, since e-mail addresses are 
case-insensitive while logins are not.

Currently system users do follow the same rules as database users, thus 
there is an equivalent system user unique identifier, call it SYSUID.

In *Java code* I can provide the identifier values you list as follows:

    String u1 = "Edward";
    String u2 = "EdWard";

    String u3 = "\"Edward\"";
    String u4 = "\"EdWard\"";

Derby's documented rules state that u1 and u2 are equivalent, thus they 
are the same identifier and the CNF of it is EDWARD (SYSUID=EDWARD).

u3 and u4 are two different identifiers (and also different to u1,u2),
thus they allow your two edwards to be distinguished, at the cost of 
having to delimit the name with quotes.

If an authentication implementation is ignoring the rules defined for 
how Derby handles user names then I'm not sure what can be done. An 
application can interface correctly into any authentication scheme by 
providing its UserAuthenticator and following the rules Derby indicates.

As I said, I think looking back it was the wrong choice to have pushed 
the SQL identifier model into the Java space, but that's how it works 
today in Derby's Java code, property files, property key-value pairs.

We could say that within a Java policy file then we follow a simple Java 
model, meaning that the user name provided corresponds to the SYSUID. 
That might make life clearer in some cases, but now consistency across 
apis goes away which may confuse the situation.

> I don't see that we have to support case-sensitive usernames in 10.4.

Could you state what you are proposing for 10.4 for system users that 
are represented by SystemPrincipals in the policy file? I'm still 
somewhat lost as you seem to be saying the system authentication has a 
different model to database authentication.


View raw message