Subject | Re: [firebird-support] Seperation of user creation and SYSBDA role |
---|---|
Author | Helen Borrie |
Post date | 2010-11-15T22:24:30Z |
At 10:03 AM 16/11/2010, Nikolaus Kern wrote:
Thus, while the effect of your conclusion seems correct, the message conveyed by your statement is not, since the RDB$ADMIN role privileges are applicable when *that* user is logged into *that* database (where the user-role association exists). Your statement will hold true only if *that* user were granted the RDB$ADMIN role in *every* database.
./heLen
>Hello Paul,Three questions, one answer: As with any ROLE, the RDB$ADMIN role must be specified in the connection parameters for its permissions to be applied. ;-)
>
>I was walking throught the documents and the webpages to trace the
>situation down. What I understand is following. Quote from
>http://www.firebirdsql.org/manual/qsg25-config.html#qsg25-config-gsec-addadmin:
>
>Co-admins must be connected with the RDB$ADMIN role if they want to add,
>modify or drop users through SQL. Since nobody can attach to the
>security database, for this to work there must be at least one other
>database where the co-admin has been granted that role. In regular
>databases, this is done with the standard GRANT statement:
>
> grant rdb$admin to bigbill
>
>If connect with user bigbill to the DB I get following result:
>
>SQL> CONNECT localhost:beta user 'bigbill' password 'bigsekrit';
>Database: localhost:beta, User: bigbill
>SQL> CREATE USER tester PASSWORD 'tester';
>Statement failed, SQLSTATE = 28000
>add record error
>-no permission for insert/write access to TABLE USERS
>
>Is there a catch 22 (between Co-Admin and RDB$ADMIN) or what do I miss
>here? Does the login of the user bigbill need any additional parameters ?
>This draws following conlusion for me:The application of ROLE is database-specific so the principle at work here is that the RDB$ADMIN-enabled user acquires elevated privileges in *that* database, which are passed transparently to the security database when it is accessed for the purpose of managing users (which are *server-wide", not database-specific).
>*) A Co-Admin needs to be DB$ADMIN in one DB to be able to
>create/alter/delete users for any other DB.
Thus, while the effect of your conclusion seems correct, the message conveyed by your statement is not, since the RDB$ADMIN role privileges are applicable when *that* user is logged into *that* database (where the user-role association exists). Your statement will hold true only if *that* user were granted the RDB$ADMIN role in *every* database.
./heLen