Question
What exactly is granting all on a URI needed for? Is it only needed when creating tables? If admins create tables on behalf of the users they already have all privileges on everything. Does a user need permissions on a URI to add partitions or not?
The following DDL command is used to add partitions to tables and works with and without specifying the LOCATION keyword:
ALTER TABLE db.tb ADD PARTITION (part=1)
ALTER TABLE db.tb ADD PARTITION (part=1) LOCATION 's3://....'
Are the URI permissions only checked on the second command?
Answer
Note: The information below may not be entirely correct as more fine-grained access permissions have been added. Refer here for current information regarding privleges.
The URI is checked anytime it is explicitly used in the DDL command, typically with the 'LOCATION' keyword in the query. This happens most commonly in 'CREATE EXTERNAL TABLE .. LOCATION 's3://...' but also when registering UDFs, alter tables to add partitions, etc. The creator must have URI access to the specified path (or a prefix of the same). This is useful for example, if you want the user to only be able to create tables over their bucket locations in S3.
This is not applicable if only admins create tables. Since they are admins, they are allowed to reference all locations in the DDL statements (and therefore only subject to the access rights of our servers). Hence, there is no reason to grant permissions on URIs if the admin creates all the tables.
This is not applicable if only admins create tables. Since they are admins, they are allowed to reference all locations in the DDL statements (and therefore only subject to the access rights of our servers). Hence, there is no reason to grant permissions on URIs if the admin creates all the tables.
Regarding the two examples given, the URI permissions are checked on the second statement only. For the first statement the path is derived implicitly from the table base table path and not checked.
See the Privileges documentation for many more details.
Comments
0 comments
Please sign in to leave a comment.