SN>> I think Interbase developers misunderstood standard
SN>> regarding roles semantics.

> Yes. But some roles stuff was made according to standard.

I dont know what the standard says, but it sounds like it was
not very clear. What I do know is that the current situation
in FB is not very friendly to use or maintain.

SN>> Actually Firebird roles may be more or less trivially
SN>> fixed to support 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.

These options have the potential to break existing
implementations. Not mine but (at least) theoretically others
due to the way roles have been documented as functioning within
Firebird (and Interbase) until now.

> But, don't allow granting role A to role B, to disable
> potential circular reference (at least).

> And, roles will be groups :-)

It seems to me that the idea of allowing roles to be granted
to roles is the only way (without introducing new security
objects and non-standard syntax) to extend the current
implementation to support a group-like security scheme.

* Circular references should be fairly easy to prevent (any
given role must only be included once).

* Current implementations would be unaffected by roles that
use roles (because they have not had this ability)

* New implementations can take advantage of roles that use
roles to implement group-like functionality.

* Such an implementation provides both "group" and (the
existing) alternative "role" scenarios to an application.


At least thats how I see it.

--
Geoff Worboys
Telesis Computing