Subject | Re[2]: [Firebird-Architect] Groups in Firebird |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2004-10-22T11:03:29Z |
Hello, Nickolay!
Friday, October 22, 2004, 4:40:26 AM, you wrote:
SN> In Oracle and most (all?) other databases roles act exactly as normal
SN> groups.
SN> Effective rights for the user are equal to union of rights granted to it
SN> directly and via roles.
Nope. That discussion (roles, groups, etc) was long time ago
in epsylon.public.interbase. What I have found for myself
that standard declares role as "alternate user identifier".
I.e. user can login using USERNAME, or login as ROLENAME,
but not both. Thus it is different with what we have in IB/FB
now.
SN> I think Interbase developers misunderstood standard regarding roles
SN> semantics.
Yes. But some roles stuff was made according to standard.
SN> Actually Firebird roles may be more or less trivially fixed to support
SN> standards-compliant behavior
Hmmm, not sure people want roles as they declared in standard.
Mostly people want user groups for SQL permissions.
So, if there statement to extend current roles functionality,
it must be:
a) allow user automatically "load" all role grants, if
user was added to role. I mean without specifying role with
login information
b) make all roles granted to user additive. If he is member
of role A and role B, let user have all grants given to
USER, PUBLIC, role A and role B.
But, don't allow granting role A to role B, to disable
potential circular reference (at least).
And, roles will be groups :-)
--
Dmitri Kouzmenko
Friday, October 22, 2004, 4:40:26 AM, you wrote:
SN> In Oracle and most (all?) other databases roles act exactly as normal
SN> groups.
SN> Effective rights for the user are equal to union of rights granted to it
SN> directly and via roles.
Nope. That discussion (roles, groups, etc) was long time ago
in epsylon.public.interbase. What I have found for myself
that standard declares role as "alternate user identifier".
I.e. user can login using USERNAME, or login as ROLENAME,
but not both. Thus it is different with what we have in IB/FB
now.
SN> I think Interbase developers misunderstood standard regarding roles
SN> semantics.
Yes. But some roles stuff was made according to standard.
SN> Actually Firebird roles may be more or less trivially fixed to support
SN> standards-compliant behavior
Hmmm, not sure people want roles as they declared in standard.
Mostly people want user groups for SQL permissions.
So, if there statement to extend current roles functionality,
it must be:
a) allow user automatically "load" all role grants, if
user was added to role. I mean without specifying role with
login information
b) make all roles granted to user additive. If he is member
of role A and role B, let user have all grants given to
USER, PUBLIC, role A and role B.
But, don't allow granting role A to role B, to disable
potential circular reference (at least).
And, roles will be groups :-)
--
Dmitri Kouzmenko