Hi, Dag. Thanks for working on the examples. You are right, a role that composes multiple roles is a good solution. I can imagine creating a role for myself: FatherHusbandColleagueFriendBrotherUncleSon :)
Are you saying that with what you're proposing, if you're granted only one role, then that's the role you would have when you connect a session? If not, shouldn't that be pretty easy to do? I see your point about sudo, but if I have only *one* role then why shouldn't that be the role I get? I can just hear myself cursing every time I have to type in "SET ROLE admin" before I can get any work done through my admin UI. Thanks, David On 9/17/07, Dag H. Wanvik <[EMAIL PROTECTED]> wrote: > > Thanks for looking at this, David! > > David Van Couvering <[EMAIL PROTECTED]> writes: > > > Hi, Dag. Thanks for this spec, this looks like a nice addition to Derby. > > > > I have a couple of comments: > > > > - It would be great to have some examples in addition to showing the > > changes to the reference manual. Identify some standard use cases > > (Create Role, Grant Role, Revoke Role, Access Resource) and show what > > commands are executed and what happens as a result. This is not just > > for reviewers' sake, but also for doc writers (and blog writers :)) > > The example you have is useful for understanding the spec, but not > > necessarily so useful for understanding the common use cases. > > That's true; the spec could have some more examples, I'll see what I > can come up with. > > > - What is the motivation to choose not to support a default role when > > a user signs in. Alternately, if a user is granted roles A and B, why > > not given them the union of the two privileges for role A and B. Why > > does the user have to select the role they want to have for a given > > session? That seems counter-intuitive. > > The roles are mutually exclusive; max one role can be set for a > session at any one time, according to the standard. This can be worked > around by creating a role containing several other roles, if desired. > > RBAC (http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf) lists > the possibility to make roles be mutually exclusive as desirable a > feature ("separation of duty"), see for example the discussion in > http://csrc.nist.gov/rbac/RBAC_DBMS_Comparison.pdf. The SQL standard > could be said to support "dynamic separation of duty" since only one > role can be set at a time. If this was the design rationale of the > standard, though, I don't know.. > > As for having a default role on connect, that could be added later. > This is implementation defined behavior, according to SQL std. It is > not my itch right now, since I am trying to limit the work in a first > increment, but I can see that it could be useful. If a user has been > granted more than one role, we would need to be able to specify > somehow which role (or none) to auto-set on connection. > > As for counter-intuitive, I am not sure that's necessarily the case, > running with max privileges isn't always what one wants, cf existence > of sudo(1). > > Thanks, > Dag >
