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
Operator REVOKE can modify rights granted to system tables at DB creation time [CORE4980] #5271
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: @aafemt Isn't it exactly what users ask for from time to time? I mean metadata security by obscurity. |
Commented by: @AlexPeshkoff The most correct solution would be to add RDB$SYSTEM_FLAG field to RDB$USER_PRIVILEGES table. But in order to not change ODS after RC1 it was decided to use RDB$GRANTOR field (set it to NULL) to mark rights granted to system objects. This solves a problem by checking for NULL field value when trying to drop records from privileges table. Also modified gbak code in order to never backup/restore rights granted to system objects. |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0.0 [ 10048 ] |
Commented by: @AlexPeshkoff Security by obscurity? |
Commented by: @pavel-zotov > As a result it's very easy to have a database from which none can read (for example) list of tables. I could NOT reproduce this on Beta2 release: C:\MIX\firebird\QA\fbt-repo\tmp>C:\MIX\firebird\oldfb30b2\isql.exe /3002:C:\MIX\firebird\QA\fbt-repo\tmp\E30B2.fdb USERADMIN2 SQL> commit; RDB$RELATION_NAMERDB$PAGES SQL> commit; USER RDB$RELATION_NAME Records affected: 3 -------------------------------------------------------------------------------------- BUT IT PASSED OK. SQL> show grants; So, what I've missed ? How to made test for this ticket ? PS. C:\MIX\firebird\oldfb30b2>findstr /r /c:"^[^#;]" firebird.conf | sort |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Done successfully Test Details: NOTE! |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @AlexPeshkoff
Some forms of SQL operator REVOKE can trash access rights to system tables. For example:
REVOKE ALL ON ALL FROM <DB-owner>
REVOKE ALL ON ALL FROM PUBLIC
REVOKE SELECT ON RDB$RELATIONS FROM PUBLIC
As a result it's very easy to have a database from which none can read (for example) list of tables.
Commits: 2e52275 e261773 ea49fca FirebirdSQL/fbt-repository@c13087b FirebirdSQL/fbt-repository@cd9c62e FirebirdSQL/fbt-repository@1395455
====== Test Details ======
NOTE!
NON-privileged user is created and used for verifying this ticket issues (rather than <db_owner> as is was specified in the source DDL expression: "REVOKE ALL ON ALL FROM <DB-owner> "). With manipulation against privileges of DB owner one may NOT to see effect of fix: seems that one may not to revoke privileges from him (letter from Alex 30-oct-2015 13:11).
The text was updated successfully, but these errors were encountered: