Subject | RE: [firebird-support] Roles |
---|---|
Author | sgarcia@cimex.com.cu |
Post date | 2005-04-20T14:29:03Z |
Thank you Helen!!!
-----Mensaje original-----
De: Helen Borrie [mailto:helebor@...]
Enviado el: Martes, 19 de Abril del 2005 10:46 pm
Para: firebird-support@yahoogroups.com
Asunto: Re: [firebird-support] Roles
At 03:30 PM 19/04/2005 -0500, Sergio wrote:
a
way to package a group of privileges. Then, all of the privileges in
that
package can be granted to a user. That user then logs in with his
username
and the role, which will enable the role's privileges for that user, for
that session.
Secondly, there is only one user that can add or delete
users: SYSDBA. This user has full destructive privileges for *all*
databases, including the security database. Users other than the SYSDBA
have very restricted privileges in the security database.
In contrast, roles apply only to the database in which they are
created. If your question meant "Is it possible to create a role with
SYSDBA privileges?" then the answer is No. A role cannot "reach out"
from
the database it belongs to, in order to gain privileges on other
databases.
If you meant "Is it possible to create a role that can grant or revoke
privileges to or from another role?" then the answer is Yes. However,
it
is a large and rather complex thing to do. The right and simple way to
address this situation is not by way of a "superuser role" but by
creating
a user and then making that user the *owner* of the database AND of all
of
the objects in the database. The owner of the database then has
complete
control of all roles and privileges in that database.
In order to be this "Superuser", i.e. the owner of everything, this user
must have created the database and the objects, typically by being the
logged-in user when the scripts to create and modify the database schema
were run.
If the owner of your database currently is SYSDBA then you have a task
to
do, in order to simplify the management of privileges. You will
literally
have to reconstruct the database from a metadata script and pump the
data
from the existing db into the new one - making sure that your Superuser
is
the logged-in user for creating the db & objects and for pumping the
data.
./heLen
Yahoo! Groups Links
-----Mensaje original-----
De: Helen Borrie [mailto:helebor@...]
Enviado el: Martes, 19 de Abril del 2005 10:46 pm
Para: firebird-support@yahoogroups.com
Asunto: Re: [firebird-support] Roles
At 03:30 PM 19/04/2005 -0500, Sergio wrote:
>Hi,First, understand that roles are not like privileged groups. A role is
>I have a couple of roles on my database (FB v1.5.2):
> R1 and
> R2
>Users of "R1" role aren't members of "R2" role, and what I want is that
>users of R1 are able to manage R2 role, that is, add or delete users of
>R2. Is that possible?
a
way to package a group of privileges. Then, all of the privileges in
that
package can be granted to a user. That user then logs in with his
username
and the role, which will enable the role's privileges for that user, for
that session.
Secondly, there is only one user that can add or delete
users: SYSDBA. This user has full destructive privileges for *all*
databases, including the security database. Users other than the SYSDBA
have very restricted privileges in the security database.
In contrast, roles apply only to the database in which they are
created. If your question meant "Is it possible to create a role with
SYSDBA privileges?" then the answer is No. A role cannot "reach out"
from
the database it belongs to, in order to gain privileges on other
databases.
If you meant "Is it possible to create a role that can grant or revoke
privileges to or from another role?" then the answer is Yes. However,
it
is a large and rather complex thing to do. The right and simple way to
address this situation is not by way of a "superuser role" but by
creating
a user and then making that user the *owner* of the database AND of all
of
the objects in the database. The owner of the database then has
complete
control of all roles and privileges in that database.
In order to be this "Superuser", i.e. the owner of everything, this user
must have created the database and the objects, typically by being the
logged-in user when the scripts to create and modify the database schema
were run.
If the owner of your database currently is SYSDBA then you have a task
to
do, in order to simplify the management of privileges. You will
literally
have to reconstruct the database from a metadata script and pump the
data
from the existing db into the new one - making sure that your Superuser
is
the logged-in user for creating the db & objects and for pumping the
data.
./heLen
Yahoo! Groups Links