Subject | RE: [Firebird-Architect] User name SYSDBA |
---|---|
Author | Leyne, Sean |
Post date | 2005-08-04T17:39:38Z |
Jim,
My goal is to make the job of security management straight-forward easy
to understand and without having to go through hoops each time you want
to perform an action.
I am trying to make the database access/security metaphor the same as
network security.
Users belong to groups/roles, object security is assigned to user or
group. User logs in; user inherits all the rights granted to them
explicitly or via their group/role membership.
No need to 'activate' role. No need to specify 'role' to perform an
action -- it's all predefined. Just go -- do the tasks/things you need
to.
If I had my way, we would drop the whole "specify role at login" but
that maybe to radical for some.
Sean
> >The whole idea of activation/deactivation seems unnecessary andbrings
> >it's own set of support issues.Why? It seems a common modus-operandi for you!
> >
> Why don't you spell out those issues rather than making us guess?
My goal is to make the job of security management straight-forward easy
to understand and without having to go through hoops each time you want
to perform an action.
I am trying to make the database access/security metaphor the same as
network security.
Users belong to groups/roles, object security is assigned to user or
group. User logs in; user inherits all the rights granted to them
explicitly or via their group/role membership.
No need to 'activate' role. No need to specify 'role' to perform an
action -- it's all predefined. Just go -- do the tasks/things you need
to.
If I had my way, we would drop the whole "specify role at login" but
that maybe to radical for some.
Sean