db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering" <da...@vancouvering.com>
Subject Re: Roles for Derby - draft spec uploaded
Date Mon, 17 Sep 2007 18:33:59 GMT
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.



On 9/17/07, Dag H. Wanvik <Dag.Wanvik@sun.com> wrote:
> Thanks for looking at this, David!
> David Van Couvering <david@vancouvering.com> 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

View raw message