db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles
Date Mon, 10 Sep 2007 21:20:29 GMT

    [ 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.


Mime
View raw message