Subject | RE: [firebird-support]Who owns my database? |
---|---|
Author | Helen Borrie |
Post date | 2006-01-26T23:23:43Z |
At 06:49 AM 27/01/2006, you wrote:
in the restored database merely by restoring it. Database ownership
is written to the database record at creation time. Ownership of
objects survives the restore because it is determined by what's
stored in the ACL which, in turn, is updated by granting and revoking
privileges. By default, only the user that created an object has
rights to it.
Views are a special case, over and above the existing table rights,
since they involve access to underlying tables and tables referenced
by those tables. In this case, granting PAUL some privileges to the
view worked, because (one way or another) PAUL had the needed rights
to the underlying objects.
You can find out who owns tables, views and procedures by looking at
RDB$OWNER_NAME in RDB$RELATIONS and RDB$PROCEDURES,
respectively. Don't be tempted to update RDB$OWNER_NAME
directly: you'll corrupt the ACL.
Think carefully about the security scheme before you start filling
RDB$USER_PRIVILEGES with a whole lot of rights that might
conflict. Work out on paper first what privs you want to give to
what types of users and devise ROLEs to group privileges
accordingly. Then it won't be necessary to grant any privileges
directly to users at all: grant a pre-packaged role to the user and
provide the means for the users to log in with username AND role.
./heLen
>Yes; but PAUL doesn't automatically become the owner of the objects
>
> > -----Original Message-----
> > In IB5.6 I have two users SYSDBA and PAUL. I cant remember
> > who I was logged
> > in as when the databases where first created but all normal operations
> > including backup and restore have been carried out as PAUL.
> > There are no
> > roles or grants or anything relating to permissions.
>
>See (http://www.fbtalk.net/viewtopic.php?id=231) for sql to discover who is
>database owner, however, if user paul is doing the restore then AFAIK this
>user owns the db.
in the restored database merely by restoring it. Database ownership
is written to the database record at creation time. Ownership of
objects survives the restore because it is determined by what's
stored in the ACL which, in turn, is updated by granting and revoking
privileges. By default, only the user that created an object has
rights to it.
Views are a special case, over and above the existing table rights,
since they involve access to underlying tables and tables referenced
by those tables. In this case, granting PAUL some privileges to the
view worked, because (one way or another) PAUL had the needed rights
to the underlying objects.
You can find out who owns tables, views and procedures by looking at
RDB$OWNER_NAME in RDB$RELATIONS and RDB$PROCEDURES,
respectively. Don't be tempted to update RDB$OWNER_NAME
directly: you'll corrupt the ACL.
Think carefully about the security scheme before you start filling
RDB$USER_PRIVILEGES with a whole lot of rights that might
conflict. Work out on paper first what privs you want to give to
what types of users and devise ROLEs to group privileges
accordingly. Then it won't be necessary to grant any privileges
directly to users at all: grant a pre-packaged role to the user and
provide the means for the users to log in with username AND role.
./heLen