Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <28285632.1189459229662.JavaMail.jira@brutus>
Date: Mon, 10 Sep 2007 14:20:29 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2207) Improve usability of Derby's
 client/server security by implementing ANSI Roles
In-Reply-To: <3404894.1167844227677.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526270 ] 

Rick Hillegas commented on DERBY-2207:
--------------------------------------

Thanks for the great spec, Dag. I have a couple comments.

General - I think that it would be nice if the introductory paragraphs of section 5 spelled out the semantics of ANSI roles in greater detail. For instance, I think that something like the following is true, but the spec doesn't exactly say this:

"At any given time, a session has a user and a role associated with it. At that point in time, the session enjoys all of the privileges explicitly granted to the user plus the transitive closure of all privileges granted to the role and its ancestors in the role graph."

A related, recurrent usage confuses me. Throughout the spec, statements like the following appear: "the privilege is revoked from any user who has the role". I don't think that granting a role to a user results in the role's privileges being granted to the user. I don't think that you can revoke those privileges from the user--you can only revoke them from the role.

Also, it would be nice if divergences from the standard were highlighted somehow.


5.6 (Granting a role to a role) - I think that cycles are not allowed in the role graph. Do you agree?


5.7 (Revoking privileges from a role) - The phrasing confuses me (see my general comment above).  I think what you are saying is that, after revoking privilege P from role A, then P is no longer enjoyed by a session operating as A or s one of its descendants in the role graph. Even this is not strictly speaking true, though--or so it seems to me. The session could still enjoy P if P is granted to some other ancestor of the current role.

I am afraid I became terribly muddled from paragraph 4 onward. It might help if you could tease apart the concepts of session, user, and role.


5.8 (Revoking a role from a user) - I got muddled in paragraph 2. Maybe teasing apart the concepts, again, would help.


5.9 (Revoking a role from a role) - I did not understand what was meant by saying that role A is also role C. I did not understand the reference to drop behavior in the previous section.


5.10 (Setting a role) - I recommend moving this section further up. I think that it will give the reader more context for understanding how a session enjoys privileges by changing role.


6.1 (The name authorization identifier name space issue) - There is lots of good discussion of the issues in this section. However, I did not come away with a clear picture of  what behavior will be implemented.


6.2 & 5.4 - I get the sense that we may be diverging from the standard here. Is this because the current GRANT/REVOKE behavior diverges from the standard?

Would it be fair to say that the set of roles is determined by the following query "select distinct roleid from sys.sysroles where grantor='_SYSTEM'". This might argue for adding a secondary index on (grantor, roleid).

Thanks!

> Improve usability of Derby's client/server security by implementing ANSI Roles
> ------------------------------------------------------------------------------
>
>                 Key: DERBY-2207
>                 URL: https://issues.apache.org/jira/browse/DERBY-2207
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security, SQL
>            Reporter: Rick Hillegas
>            Assignee: Dag H. Wanvik
>         Attachments: spec.html
>
>
> Implementing ANSI Roles will make it easier to manage security for multi-user applications with high user turnover.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.