Sergio Peña commented on SENTRY-2264:

The ALTER privilege is also required in the source table as it is the action 
the user is doing ALTER TABLE.
We don't have a DELETE privilege yet, so should we treat this case as the user 
requires ALL privileges in the source table instead?

Why is the ALTER privilege required on the destination?

Is the INSERT on the database needed? This means the user won't be able to move 
tables between databases they have CREATE privileges. The CREATE comes with 
OWNER privileges, so the user will end up having ALL privileges in the table 
anyway. Which brings an interesting question, if I have ALL privileges (but not 
ownership) and I move the table, then I will transfer the ownership to me. We 
need to check if HMS generates only an ALTER operation in this cases of if it 
generates DROP and CREATE events which will complicate things.

If ownership is disabled, then If the user has ALL privileges in the source 
table, then when moving the table those privileges will be moved so the user 
will have ALL privileges in the destination table.

> It is possible to elevate privileges from DROP using alter table rename
> -----------------------------------------------------------------------
>                 Key: SENTRY-2264
>                 URL: https://issues.apache.org/jira/browse/SENTRY-2264
>             Project: Sentry
>          Issue Type: Bug
>          Components: Sentry
>    Affects Versions: 2.1.0
>            Reporter: Na Li
>            Assignee: Na Li
>            Priority: Major
>         Attachments: SENTRY-2264.001.patch, SENTRY-2264.002.patch
> After introducing FGP, a user with only DROP on a database db1 and at least 
> CREATE on db2 can run ALTER TABLE RENAME db1.table1 db2.table2, and thus 
> elevate their privileges.
> To reproduce:
> As admin (e.g. hive):
> 1. Create db1, db1.table1, db2, role r1.
> 2. Grant DROP on db1 to role r1.
> 3. Grant ALL on db2 to role r1
> 4. Grant role r1 to user testuser1.
> As testuser1:
> 1. use db1; alter table db1.table1 rename to db2.table1
> 2. select * from db2. table1
> Result: the select command succeeds.
> Desired behavior:
> we should at least require following privileges to execute the table rename 
> command:
> table level "SELECT" and database level "DELECT" at source
> database level "CREATE" at destination.
> The reason we don't require "alter, insert" for destination DB is that 
> "alter" and "insert" is table level privileges and when "alter table rename" 
> command is executed, there is no table in destination DB. So we cannot 
> enforce these table level privileges. Therefore the only change is add 
> table-level "select" privilege in required input privileges

This message was sent by Atlassian JIRA

Reply via email to