I am working with Firebird 2.5.8, ODS Version 11.2, connecting via Firebird ADO.NET v6.6 (in C# using Visual Studio). I have built a database management tool for configuring our tables, as well as performing some basic Firebird user management operations. The database has different roles (MyRoleX and MyRoleY) defined to give/restrict access.
User management operations include granting/revoking these roles to different users. When logged into the tool, the connection uses the RDB$ADMIN ROLE and the connected user has been created with the ADMIN ROLE. Lastly, there may be more than one Firebird user of the tool (e.g. Mgr1 and Mgr2).
Ok, so Mgr1 CREATEs a new user, along with:
GRANT MyRoleX TO UserA;
GRANT MyRoleY TO UserA;
Mgr1 then is off shift/vacation/unavailable, and Mgr2 realizes UserA should not have been granted MyRoleY. But when Mgr2 logs in and tries to run the command:
REVOKE MyRoleY FROM UserA;
the error message is given:
unsuccessful metadata update
Mgr2 is not grantor of Role on MyRoleY to UserA.
and if the command is changed to:
REVOKE MyRoleY FROM UserA GRANTED BY Mgr1;
then an error message is given:
unsuccessful metadata update
Only SYSDBA or database owner can use GRANTED BY clause.
While the 2nd message is explicitly clear, why, if both Mgr1 and Mgr2 are connected using ROLE=RDB$ADMIN (and of course these users are granted ADMIN ROLE), can they NOT perform this operation?
From Statements for Revoking Privileges , under the heading 'Revoking Privileges That Were GRANTED BY' it states:
the current user must be logged in either with full administrative privileges
If logged in under under RDB$ADMIN, is that not full admin privileges?
At the top of the link under the heading 'RDB$ADMIN Role', it also states:
Assigning the RDB$ADMIN role to a regular user in a database grants that user the privileges of the SYSDBA.
So why then does Mgr2 have privilege like SYSDBA?
Some questions seeking answers:
Am I doing anything wrong here? Is there a way to connect or allow Mgr2 to REVOKE GRANTs to ROLEs made by Mgr1?
We do NOT want to be sharing the SYSDBA nor database owner credentials to perform these operations, so any other solutions?