Issue Details (XML | Word | Printable)

Key: CORE-1869
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Konstantin Dombrugov
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Roles granting/revoking logic (differs between 2.0 and 2.1)

Created: 26/Apr/08 09:01 AM   Updated: 12/Nov/09 04:50 PM
Component/s: Documentation
Affects Version/s: 2.1.0
Fix Version/s: 2.5 Alpha 1

Time Tracking:
Not Specified

Environment: 2.1.0

Planning Status: Unspecified


 Description  « Hide
There is a difference between role granting/revoking between 2.0.4 and 2.1.0 wich is currently undocumented.
EPISODE ONE: grant/revoke

//login as sysdba
create role "role01";
grant "role01" to user01 with admin option
//login as user01
grant "role01" to user02
//login as sysdba
grant "role01" to user02 with admin option
//login as user01
revoke "role01" from user02

<last command works ok (removes record from RDB$USER_PRIVILEGES wich grants role01 to user02 by user01) for 2.0 but fails in 2.1 persisting record in RDB$USER_PRIVILEGES with message
*This operation is not defined for system tables.Unsuccessful metadata update.
USER01 is not grantor of <Unknown> on Role01 to USER02.* >

//and if in FB 2.1.0 sysdba execute
revoke "role01" from user02
//role01 will be unavailable to user02 (access granted by user01 will be removed too)

Please explain how it works or how it should realy work, because I cannot find description of such changes in release notes.

EPISODE TWO: admin option
//as sysdba
create role "role01";
grant "role01" to user01 with admin option;
//as user01
grant "role01" to user03 with admin option;
//as sysdba
grant "role01" to user02 with admin option;
//as user01
//this removes admin option from user02
grant "role01" to user02;
//as user03
grant "role01" to user02 with admin option;
//as user02
grant "role01" to public
<Last command fails with *This operation is not defined for system tables.Unsuccessful metadata update.
User USER02 has no grant admin option on SQL role Role01.*>

Should it work like that?

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 28/Apr/08 04:49 AM
No sure for the rest, but unability for SYSDBA to revoke something was definitely a bug in 2.0.

Alexander Peshkov added a comment - 10/Jun/08 07:10 AM
To solve this problem I had to add new clause to GRANT and REVOKE commands - GRANTED BY. Only using it it's possible to avoid conflicts with roles (and other rigths) assignment when performed by many users.
This also means backporting is problematic - we do not add new features in old versions.