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> "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> 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> Also, it would be nice if divergences from the standard were highlighted somehow.
Agreed. I will do that.
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
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> 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> 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> 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
It should read "unless A is also contained in (not through B) another
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> 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> 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> 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'".
Rick> This might argue for adding a secondary index on (grantor,
Yes, I agree.