[MDEV-14443] DENY clause for access control a.k.a. "negative grants" Created: 2017-11-20  Updated: 2023-12-22

Status: Stalled
Project: MariaDB Server
Component/s: Authentication and Privilege System
Fix Version/s: 11.5

Type: New Feature Priority: Critical
Reporter: Hanzhi (Inactive) Assignee: Vicențiu Ciorbaru
Resolution: Unresolved Votes: 7
Labels: gsoc18

Attachments: PDF File Rutuja-Reverse-Priv-Dec-18.pdf    
Issue Links:
Blocks
is blocked by MDEV-29458 Role grant commands do not propagate ... Closed
is blocked by MDEV-29465 Inherited columns privs for roles wro... Closed
is blocked by MDEV-29509 execute granted indirectly (via roles... Closed
Duplicate
Relates
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MDEV-31741 Refactoring and cleanups in preparati... Technical task Stalled Vicențiu Ciorbaru  

 Description   

Summary:

Implement a way to ensure that a user can not get access to a particular resource.
DENY will function as a separate set of rules for access control. If any resource (global, database, table, column, procedure, function, etc.) has a deny on one particular privilege, it is impossible to gain that privilege unless the DENY is revoked.

For example:

GRANT SELECT on *.* to alice;
DENY SELECT on db.secret_table to alice;

alice will not be able to select from secret_table.

Syntax:

       DENY <privilege-list> ON <object-list> TO   <user-or-role>
 
REVOKE DENY <privilege-list> ON <object-list> FROM <user-or-role>

User cases

https://stackoverflow.com/questions/6288554/mysql-grant-all-privileges-to-database-except-one-table (32k views)
https://dba.stackexchange.com/questions/98949/grant-select-on-all-databases-except-one&#45;mysql (18k views)
https://dba.stackexchange.com/questions/68957/block-user-access-to-certain&#45;tables (13k views)

Details:

  1. Users should not be able to see that a DENY is assigned to them. Similar to how databases that the user can not access are not visible in show databases.
  2. DENY works on roles (as well as PUBLIC when it is implemented)
  3. Enabling a role activates that role's denies as well.
  4. Denies will be visible in SHOW GRANTS [FOR] if:
    • User has read or write access to mysql database.
    • User has read or write access to corresponding mysql privilege table. (TODO for as a separate MDEV for SHOW GRANTS)
  5. Methods of querying denies: INFORMATION_SCHEMA.USER_PRIVILEGES
  6. Introduce a form of SUPER privilege, say IGNORE_DENIES, to allow a "superuser" to ignore denies (this is compatible with SQL Server DENY behavior)

Compatiblity with other databases (Potential future work)

SQL Server

  • Compared to SQL Server, DENY can only be revoked via REVOKE DENY. Future possibility for SQL Server compatibility (via SQL_MODE=MSSQL) GRANT can also cancel a DENY.
  • An SQL Server quirk is that column level denies take precedence over table level denies. This is a deprecated functionality of SQL Server, meant for backwards compatibility.

MySQL

  • MySQL treats revokes as "holes" that are filled when the privilege is granted (directly or via a a higher level grant). Deny will remain in effect in our implementation.
  • To allow MySQL compatibility, a possible extension in the future is: @@partial_revokes=1 -> REVOKE also works as DENY.

Implementation details:

  • Current privilege checking order first checks global, database, table, column privileges (in this order). If at any point the needed privileges are met, the privilege checking code stops execution. Introducing denies will require an additional lookup, one for each individual resource accessed. Some form of quick lookup must be made to answer:
    • Does this user have denies for databases? (if global privileges met all required access bits).
    • Does this user have denies for tables in a particular database (if database level privileges met all required access bits).
    • Does this user have denies on table columns for a particular table (if table level privileges met all required access bits).
  • Should denies be stored in global_priv only, or should corresponding mysql.db, mysql.table_priv, etc. tables also have a "DENY" column?

Milestones (each milestone includes test cases showcasing functionality):

  1. Grammar
  2. Global denies
  3. Database denies
  4. Table level denies
  5. Column level denies
  6. Stored procedure denies
  7. Information schema tables


 Comments   
Comment by Ralf Gebhardt [ 2018-11-10 ]

cvicentiu, rutuja, Please add a rough estimate for the remaining work

Comment by Rutuja Surve (Inactive) [ 2019-01-22 ]

Current status:
1. User level (Global) deny works with and without an initial GRANT.
2. Database level deny works without an initial GRANT.
Attaching the detailed approach followed for the same shortly.

Comment by Rutuja Surve (Inactive) [ 2019-05-05 ]

Current status of implementation:
User and database level denies work end to end.
Work in progress for table and column level deny (estimate 1 week)
Routine level deny (estimate 1 week)
Testing and review (estimate 2 weeks)

Comment by Ben Stillman [ 2020-08-25 ]

As discussed with Max a while back, this functionality is highly desired by the SkySQL team to revoke access to system schemas.

Comment by Jim Parks (Inactive) [ 2021-05-20 ]

The problem I see with that is just that if you later grant some privileges
that contradict the earlier REVOKE, then what will the expected behavior
be? I like the idea of a DENY that overrides any existing or future grants.

JP

On Thu, May 20, 2021 at 7:13 AM Ralf Gebhardt (Jira) <jira@mariadb.org>

Comment by Manjot Singh (Inactive) [ 2021-11-10 ]

If there is a DENY on mysql.* for a user and they try to run:

mysql < mydump.sql

the full dump should load but avoid the mysql.* tables (or have only warnings related).

Comment by Manjot Singh (Inactive) [ 2021-11-10 ]

if there is a DENY on mysql.* .. GRANT and related syntax should still be allowed

Comment by Vicențiu Ciorbaru [ 2021-11-22 ]

manjot DENY cancels out privileges.

For example if a user could create a user with CREATE USER privilege, but otherwise didn't have INSERT/UPDATE rights on mysql.* database, then the same would be true if the user had DENY INSERT UPDATE on mysql.*.

I assume this is in line with your statements, correct?

Comment by Vicențiu Ciorbaru [ 2021-12-23 ]

A current status update on the feature:

In order to facilitate the feature, I have done the following cleanups:

  1. Move check_xxx_access functions to sql_acl.cc.
  2. Uniform privilege modification functions for mysql.user and the newer mysql.global_priv table. This is to facilitate writing denies into mysql.global_priv table.
  3. Optimize Sql_cmd_grant class, to use composition instead of inheritance. This also had the added benefit of reducing memory usage for Grant commands, avoiding an extra copy in LEX structure.
  4. Clean up the sql_acl.h exposed API. Many of the functions are now behind Sql_cmd_grant::execute calls.
  5. Remove code duplication by converting double acl_get calls checking for user and role privileges into a single function. This will facilitate DENY checks as well.
  6. Introduce a Priv_spec class that defines a delta of privileges. This is used uniformly by replace_xxxx_table functions to apply privilege deltas. This facilitates DENY and /REVOKE DENY grants.
  7. Split mysql_grant function into separate components. This facilitates individual DENY level grants (Global, Database, Proxy) This has the added benefit of only locking the modified privilege tables when doing a grant update.
  8. Cache get_current_user results in Sql_cmd_grant, before calling mysql_grant_xxx functions. This simplifies a lot of the mysql_grant_xxx functions.
  9. Refactor test_if_create_new_users, similar to get_current_user caching. This will facilitate hooking up denies too.
  10. Extend gramar in sql_yacc.yy to cover DENY clause.
  11. Code to read DENY specification from mysql.global_priv table. The JSON format at this point is:

          {
            "global": int
            "db": [
              {
                "name": str
                "access": int
              },
            ]
            "table": [
              {
                "name": str
                "access": int
              },
            ]
      }
    The format will be extended to cover finer level denies (table columns) too.
    

  12. JSON reader class, used to parse the DENY json and create in-memory HASH tables for all deny entries - per user.
  13. Extend mysql_show_grants to also output denies.
  14. Wrote test cases to cover currently implemented functionality, as well as tests that currently fail (because denies are not properly enforced). Using effectively test driven development to ensure all code paths are covered.

TODO items:

  1. Adjust privilege check call sites to do proper deny evaluation. Ideally, create a uniform API that abstracts away both user and role current grants and denies.
  2. Extend information schema tables to present user denies.
  3. Create a new privilege (IGNORE_DENIES) to allow a user to bypass denies.
  4. Extend mysql_show_grants to output grants for users who have denies, but do not have the rights to see those denies. This requires a dedicated algorithm to generate the equivalent set of rights that are available.
  5. Extend test coverage.
  6. Code documentation - both within source as well as in the KB.
Comment by Christine Lieu (Inactive) [ 2022-06-22 ]

cvicentiu the Xpand team is going to start implementing this feature as well. Is there a build that we could use to compare notes?

Comment by Vicențiu Ciorbaru [ 2022-09-07 ]

Hi Sergei!

Once you are done with reviewing MDEV-29458 & MDEV-29465, please start looking at the code here:

https://github.com/MariaDB/server/pull/2258

Things currently not completely operational:
1. SHOW GRANTS currently only shows up-to database level denies.
2. Wildcard DB denies.

I'm looking for general input on architecture changes as well as functionality. I expect that by the time you get to the end of the commit tree that the missing items will also be present.

Comment by Vicențiu Ciorbaru [ 2023-06-14 ]

One status update on this:

I've rebased on top of 11.2.

As discussed with Sergei Golubchik, I've implemented the separation of denies between users and roles. The implementation still requires testing and I am uncovering edge cases, bugs and an occasional crash. I expect around a week worth of work to stabilize this, then it should be ready for one final review.

Generated at Thu Feb 08 08:13:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.