New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to grant role to another role [CORE1815] #2245
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: pabloj (pabloj) It would be really nice to have this feature implemented |
Modified by: @dyemanovFix Version: 3.0 Alpha 1 [ 10331 ] |
Modified by: @dyemanovFix Version: 3.0 Beta 1 [ 10332 ] => |
Modified by: @romansimakovassignee: Alexander Peshkov [ alexpeshkoff ] => Roman Simakov [ roman-simakov ] |
Commented by: @romansimakov Read doc/sql.extensions/README.cumulative_roles.txt for description |
Modified by: @romansimakovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 Alpha 1 [ 10731 ] |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Deferred Test Details: Wait for reply from Alex, letter 16-may-2016 19:37 (issue about missing warnings/errors when some user "Boss1" tries to grant privilege to user "Sale1", but this "Sale1" already has this privilege and it was granted to him by user "Boss2"; after this Boss1 can issue 'revoke ... from Sale1' and he will NOT get error but privilege silently remains alive). |
Commented by: @pavel-zotov 2 Alex, Roman: gentlemens, can you please clarify my issue about 'silent' rejection of REVOKING role if before this statement we have GRANT this role to user who was granted this role by another user (e.g., sysdba) ? Look at this example (it's also can be found in my letter of 15-may-2016 16:14, subject: "cumulative_roles ... "):
=== When statement [1] is commented, statement [2] will raise:Statement failed, SQLSTATE = 42000
|
Commented by: @romansimakov Description of what heppens without conclusion for now. In case of commented [1] all works correctly. |
Commented by: @pavel-zotov > 2. If uncomment [1] user boss grants role rboss to acnt again and UP also store a record about it but with grantor BOSS. Note UP now has 2 records! IMHO, some kind of warning is reqeuired here! |
Commented by: @romansimakov I cannot understand SQL Standard requirements. Regarding ADMIN OPTION it's obvious. If A grant R to U and B grant R to U with admin option it's must be two records about it. I see following options: |
Commented by: @romansimakov I've checked ORACLE and it looks like it has no GRANTOR at all! [1] pass silent and do nothing and [2] revokes rboss completely. GRANTEE GRANTED_ROLE ADM DEF As you can see to there is no GRANTOR field. |
Commented by: @dyemanov After taking a careful look at the SQL spec, I see that FB has a few mismatches: - it's impossible to grant role to PUBLIC (allowed by the standard) The standard declares that REVOKE destroys only privileges granted by CURRENT_USER or CURRENT_ROLE, it does not touch privileges granted by others. This means that storing multiple descriptors (records in UP) is correct. So AFAIU the Pavel's test works almost correctly. By "almost" I mean that with the commented line [1] the error should either be different (e.g. "nothing to revoke") or not being raised at all (acting as silent no-op). Grantors are also needed for supporting the CASCADE option: in this case the entire graph is destroyed, e.g. if R is granted to U2 by U1 WITH ADMIN OPTION and then R is granted to U3 by U2 and then U1 executes REVOKE ROLE R FROM USER U2 CASCADE, this means that both U1->U2 and U2->U3 descriptors are removed. |
Commented by: @dyemanov Or maybe a better error message would be something like "no match found for role RBOSS granted to ACNT by BOSS". |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Deferred => Done with caveats Test Details: Wait for reply from Alex, letter 16-may-2016 19:37 (issue about missing warnings/errors when some user "Boss1" tries to grant privilege to user "Sale1", but this "Sale1" already has this privilege and it was granted to him by user "Boss2"; after this Boss1 can issue 'revoke ... from Sale1' and he will NOT get error but privilege silently remains alive). => Wait for reply from Alex, letter 16-may-2016 19:37 (issue about missing warnings/errors when some user "Boss1" tries to grant privilege to user "Sale1", but this "Sale1" already has this privilege and it was granted to him by user "Boss2"; after this Boss1 can issue 'revoke ... from Sale1' and he will NOT get error but privilege silently remains alive). 11-aug-2016: committed intermediate version of test. |
Submitted by: Anderson Farias (afarias)
Replaces CORE751
Votes: 5
Ability to grant role to another role so that it 'inherits' the former privileges.
Eg.
create role base_role_1;
grant all on some_table to base_role_1;
create role base_role_2
grant execute on procedure some_proc to base_role_2;
create role master_role;
grant base_role_1 to master_role;
grant base_role_2 to master_role;
grant ... (especific privileges)
so that 'master_role' have the same privileges as 'base_role_1' and 'base_role_2'. AND if priveleges are granted to or revoked from it's assigned roles than it gets atomaticaly 'afected'
Commits: 238fff3
====== Test Details ======
Wait for reply from Alex, letter 16-may-2016 19:37 (issue about missing warnings/errors when some user "Boss1" tries to grant privilege to user "Sale1", but this "Sale1" already has this privilege and it was granted to him by user "Boss2"; after this Boss1 can issue 'revoke ... from Sale1' and he will NOT get error but privilege silently remains alive).
11-aug-2016: committed intermediate version of test.
The text was updated successfully, but these errors were encountered: