Subject | Re: [firebird-support] Can non-sysdba really alter users? |
---|---|
Author | Thomas Steinmaurer |
Post date | 2012-09-17T12:07:19Z |
Hello Tomasz,
Windows 7 Prof.
C:\Firebird\Firebird_252_3051\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect localhost/3051:fbsmptest_1.fdb user sysdba password masterkey;
Database: localhost/3051:fbsmptest_1.fdb, User: sysdba
SQL> create user utest password 'utest' grant admin role;
SQL> commit;
SQL> grant rdb$admin to utest;
SQL> commit;
SQL> connect localhost/3051:fbsmptest_1.fdb user utest password utest
role RDB$ADMIN;
Database: localhost/3051:fbsmptest_1.fdb, User: utest, Role: RDB$ADMIN
SQL> create user utest2 password 'utest2';
SQL> commit;
SQL> alter user utest2 password 'utest3';
SQL> commit;
SQL> connect localhost/3051:fbsmptest_1.fdb user utest2 password utest3;
Database: localhost/3051:fbsmptest_1.fdb, User: utest2
SQL>
Perhaps it might be related to CORE-3398, but I'm not sure. Any chance
to give 2.5.1 or 2.5.2 RC1 a try?
--
With regards,
Thomas Steinmaurer
http://www.upscene.com/
> I'd be very grateful if someone could repeat the scenario describedThe following works fine for me with Firebird 2.5.2 RC1 64-bit on
> below and confirm I'm not daydreaming (should take about 1 minute). I've
> tested it on FB 2.5.0.26074 CS (Linux 32 and 64 bit).
>
> According to
>
> http://www.firebirdsql.org/refdocs/langrefupd25-security-sql-user-mgmt.html
>
> any user with RDB$ADMIN role in the security database and at least one
> other database should be able to create/alter/drop other users.
> If so, in my opinion the following scenario should complete without
> errors (creating a new database is not relevant, but I included it to
> make sure we start from a clean setup).
>
> 1. Run isql as SYSDBA and execute:
> create database 'test.fdb';
>
> 2. Close isql, run it again and connect to test.fdb as sysdba (e.g. isql
> -user sysdba -password topsecret test.fdb) and execute:
> create user U1 password '1';
> commit;
> alter user U1 grant admin role;
> commit;
> grant RDB$ADMIN to U1;
> commit;
>
> 3. Close isql. At this point, we have a user U1, who satisfies the
> requirements from the manual mentioned above. So, run isql again,
> connecting as the new user:
> isql -user U1 -password 1 -role 'RDB$ADMIN' test.fdb
> and execute:
> create user U2 password '1';
> commit;
> alter user U2 password '2';
> commit;
>
> The last alter user statement fails with message
>
> Statement failed, SQLSTATE = HY000
> record not found for user: U2
>
> However, the create user works fine (gsec shows, that U2 had been
> created). Any subsequent attempts to change U1 fail, though.
> Is there anything I'm missing? Should I somehow tell Firebird that, when
> connecting as U1, I'd like to assume admin role not only in test.fdb,
> but also in the security database?
>
> Any help appreciated.
Windows 7 Prof.
C:\Firebird\Firebird_252_3051\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect localhost/3051:fbsmptest_1.fdb user sysdba password masterkey;
Database: localhost/3051:fbsmptest_1.fdb, User: sysdba
SQL> create user utest password 'utest' grant admin role;
SQL> commit;
SQL> grant rdb$admin to utest;
SQL> commit;
SQL> connect localhost/3051:fbsmptest_1.fdb user utest password utest
role RDB$ADMIN;
Database: localhost/3051:fbsmptest_1.fdb, User: utest, Role: RDB$ADMIN
SQL> create user utest2 password 'utest2';
SQL> commit;
SQL> alter user utest2 password 'utest3';
SQL> commit;
SQL> connect localhost/3051:fbsmptest_1.fdb user utest2 password utest3;
Database: localhost/3051:fbsmptest_1.fdb, User: utest2
SQL>
Perhaps it might be related to CORE-3398, but I'm not sure. Any chance
to give 2.5.1 or 2.5.2 RC1 a try?
--
With regards,
Thomas Steinmaurer
http://www.upscene.com/