GRANT on unknown objects need to be rejected

[jeeminso]

CrateDB version

latest master

CrateDB setup information

No response

Problem description

Please see steps to reproduce.

Steps to Reproduce

cr> create table q (a int);                                                                                                                                           
CREATE OK, 1 row affected  (1.652 sec)
cr> create view qv as select * from q;                                                                                                                                
CREATE OK, 1 row affected  (0.493 sec)
cr> grant dql on table qv to john;  -- qv is not a table but a view but the stmt succeeded                                                                                                                                  
GRANT OK, 1 row affected  (0.085 sec)
cr> grant dql on schema q to john; -- schema q does not exist but the stmt scceeded                                                                                                                                   
GRANT OK, 1 row affected  (0.079 sec)

cr> select * from sys.privileges;                                                                                                                                     
+---------+---------+---------+--------+-------+------+
| class   | grantee | grantor | ident  | state | type |
+---------+---------+---------+--------+-------+------+
| SCHEMA  | john    | crate   | q      | GRANT | DQL  |
| TABLE   | john    | crate   | doc.qv | GRANT | DQL  |  -- qv is a view not a table
+---------+---------+---------+--------+-------+------+
SELECT 7 rows in set (0.002 sec)

cr> show schemas;                                                                                                                                                     
+--------------------+
| schema_name        |
+--------------------+
| blob               |
| doc                |
| information_schema |
| pg_catalog         |
| scheduler_issue    |
| sys                |
+--------------------+
-- schema 'q' does not exist

Actual Result

Privileges on unknown objects granted.

Expected Result

Such stmts need to be rejected.

[jeeminso]

Just by looking at the behaviours, the objects seem to be not analyzed. There will be more variations around this but I would presume a single fix will address all.

[proddata]

I am pretty sure at least for schemas this is intentional, as they are not explicitly created and therefore a user would need to have access to a schema before the first object within it exists.

(Personally I'd prefer for schemas to also be explicitly created)

[matriv]

I don't have a clear opinion if this is a bug or a desired behavior.

A bit related, need to test, what happens if you attempt to restore users/roles & their privileges to a new cluster, if the tables/views/schemas are not still there? Maybe it can be handy for such cases to prepare the users/roles & privileges (manually, or with saved statements) before the DB objects are created. Additionally, agreeing with @proddata, since currently we don't have empty schemas, (always need to have the 1st table created within them, and we dont' have a DROP SCHEMA stmt), seems valid to be able to assign privileges to a schema that doesn't exist.

On the other, hand it is weird to select from sys.privileges and see privs for object not existing on the cluster.

[matriv]

I am pretty sure at least for schemas this is intentional, as they are not explicitly created and therefore a user would need to have access to a schema before the first object within it exists.

(Personally I'd prefer for schemas to also be explicitly created)

I'm guessing that after: #11939, we can consider implementing the explicit creation/dropping of schemas.

[matriv]

After discussion we decided to treat this as an improvement, rather than a bug fix.

[matriv]

Some extra info, currently you can restore USERMANAGEMENT, and the privileges are there even though the objects are not:

cr> RESTORE SNAPSHOT repo.snap1 USERMANAGEMENT;
RESTORE OK, 1 row affected  (0.052 sec)
cr> select * from sys.privileges;
+-------+---------+---------+-------+-------+------+
| class | grantee | grantor | ident | state | type |
+-------+---------+---------+-------+-------+------+
| TABLE | matriv  | crate   | doc.t | GRANT | DML  |
+-------+---------+---------+-------+-------+------+
SELECT 1 row in set (0.003 sec)
cr> select * from t;
RelationUnknown[Relation 't' unknown]

If we go ahead to implement throw errors when trying to grant privs on non-existing objects, this will contradict with the restore privs behavior.

[proddata]

I would maintain the current behavior until we decide to explicitly create schemas. Once we do, we can more closely link privileges to objects and potentially drop privileges if the associated object no longer exists.