db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Roles for Derby - draft spec uploaded
Date Mon, 17 Sep 2007 16:22:15 GMT

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


View raw message