You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
isql -u sysdba -p masterkey employee
Database: employee, User: SYSDBA
SQL> create user adm password 'adm';
SQL> grant RDB$ADMIN to adm;
SQL> exit;
isql -u adm -p adm -r RDB$ADMIN employee
Database: employee, User: ADM, Role: RDB$ADMIN
SQL> create role test_role;
SQL> grant test_role to sysdba;
SQL> exit;
isql -u sysdba -p masterkey employee
Database: employee, User: SYSDBA
SQL> revoke test_role from sysdba;
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-REVOKE failed
-SYSDBA is not grantor of ROLE on TEST_ROLE to SYSDBA.
It's because of a complex condition in the GrantRevokeNode::grantRevoke method in which the check of the "GRANT_REVOKE_ON_ANY_OBJECT" privilege comes after checking that the user has granted the permission themselves.
This condition have been added in #5527.
But I see no reason to prevent a user with the "GRANT_REVOKE_ON_ANY_OBJECT" privilege from revoking permissions.
The text was updated successfully, but these errors were encountered:
Here are the steps to reproduce:
isql -u sysdba -p masterkey employee
Database: employee, User: SYSDBA
SQL> create user adm password 'adm';
SQL> grant RDB$ADMIN to adm;
SQL> exit;
isql -u adm -p adm -r RDB$ADMIN employee
Database: employee, User: ADM, Role: RDB$ADMIN
SQL> create role test_role;
SQL> grant test_role to sysdba;
SQL> exit;
isql -u sysdba -p masterkey employee
Database: employee, User: SYSDBA
SQL> revoke test_role from sysdba;
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-REVOKE failed
-SYSDBA is not grantor of ROLE on TEST_ROLE to SYSDBA.
It's because of a complex condition in the GrantRevokeNode::grantRevoke method in which the check of the "GRANT_REVOKE_ON_ANY_OBJECT" privilege comes after checking that the user has granted the permission themselves.
This condition have been added in #5527.
But I see no reason to prevent a user with the "GRANT_REVOKE_ON_ANY_OBJECT" privilege from revoking permissions.
The text was updated successfully, but these errors were encountered: