db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (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 22:42:29 GMT

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

Dag H. Wanvik commented on DERBY-2207:
--------------------------------------

Thanks for the quick response, Rick!

I will answer your comments here for now and upload a new version as
soon as I have incorporated your suggestions.


>>>>> Rick Hillegas (JIRA) writes:

Rick> General - I think that it would be nice if the introductory
Rick> paragraphs of section 5 spelled out the semantics of ANSI roles
Rick> in greater detail. For instance, I think that something like the
Rick> following is true, but the spec doesn't exactly say this: 
Rick>
Rick> "At any given time, a session has a user and a role associated
Rick> with it. At that point in time, the session enjoys all of the
Rick> privileges explicitly granted to the user plus the transitive
Rick> closure of all privileges granted to the role and its ancestors
Rick> in the role graph."

You are right, it will be good to spell out basic behavior better in
the introductory paragraph. 

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

You are correct.  A user session that has set the role, however, could
possibly lose that privilege from its set of current privileges. I
will try to find such occurences and clarify.

Rick> I don't think that you can revoke those privileges
Rick> from the user--you can only revoke them from the role.

Correct. Revoking a privilege from a role only revokes it from the
set of privileges granted to that role. Only a "revoke privilege from
user" statement will revoke privileges from a user. 

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

Agreed. I will do that.

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

I think I say that in the first paragraph of 5.6 ? ".. can not contain
cycles.."

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

Again, I see I have used "user" when thinking of "user session", will
clarify throughout, thanks! What you say next is also correct.

Rick> 
Rick> I am afraid I became terribly muddled from paragraph 4
Rick> onward. It might help if you could tease apart the concepts of
Rick> session, user, and role.
Rick> 
Rick> 
Rick> 5.8 (Revoking a role from a user) - I got muddled in paragraph
Rick> 2. Maybe teasing apart the concepts, again, would help.

I am afraid the lack of precision reflects my own process of digesting
this and trying to paraphrase the verbose semantic descriptions in the
standard down to something readable,  Rick! ;) I will have another go
at this section!

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

It should read "unless A is also contained in (not through B) another
role C". 

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

Good idea, thanks.

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

Right, I have not decided. Suggestions are welcome!

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

Do you mean "5.2 No initial role"? This is according to the standard.
For 5.4, yes, I think this is a deviation, in the the dbo has
automatic power to gtant any privilege. I model this on the current
behavior (who can grant a privilege to a user: dbo + object owner).

Rick> 
Rick> Would it be fair to say that the set of roles is determined by
Rick> the following query "select distinct roleid from sys.sysroles
Rick> where grantor='_SYSTEM'". 

Yes.

Rick> This might argue for adding a secondary index on (grantor,
Rick> roleid).

Yes, I agree.


> 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