[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[
https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523381#comment-16523381
]
Hadoop QA commented on SENTRY-2264:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12929144/SENTRY-2264.004.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/3924/console
This message is automatically generated.
> 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,
> SENTRY-2264.003.patch, SENTRY-2264.004.patch, SENTRY-2264.004.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 "ALL" 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 "ALL" privilege in required input privileges to avoid elevate
> privilege by moving table cross DB
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[ https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523199#comment-16523199 ] Na Li commented on SENTRY-2264: --- [~spena] owner privilege related issues are tracked in SENTRY-2280 > 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, > SENTRY-2264.003.patch, SENTRY-2264.004.patch, SENTRY-2264.004.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 "ALL" 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 "ALL" privilege in required input privileges to avoid elevate > privilege by moving table cross DB -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[ https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523176#comment-16523176 ] Na Li commented on SENTRY-2264: --- The failed test is not related to my fix. It is more likely caused by timing of the test. > 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, > SENTRY-2264.003.patch, SENTRY-2264.004.patch, SENTRY-2264.004.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 "ALL" 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 "ALL" privilege in required input privileges to avoid elevate > privilege by moving table cross DB -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[
https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523167#comment-16523167
]
Hadoop QA commented on SENTRY-2264:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12929140/SENTRY-2264.004.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.provider.db.generic.service.persistent.TestPrivilegeOperatePersistence
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/3923/console
This message is automatically generated.
> 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,
> SENTRY-2264.003.patch, SENTRY-2264.004.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 "ALL" 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 "ALL" privilege in required input privileges to avoid elevate
> privilege by moving table cross DB
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[ https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523163#comment-16523163 ] Na Li commented on SENTRY-2264: --- [~spena] The ALL privilege will be required for source table to avoid elevating privilege when renaming table cross databases. Only create privilege is required on destination database. Can we handle owner privilege related issue in another jira? This one focuses on tighten privilege requirement for source table for table rename. > 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, > SENTRY-2264.003.patch, SENTRY-2264.004.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 "ALL" 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 "ALL" privilege in required input privileges to avoid elevate > privilege by moving table cross DB -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[
https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523116#comment-16523116
]
Hadoop QA commented on SENTRY-2264:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12929103/SENTRY-2264.003.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/3921/console
This message is automatically generated.
> 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,
> SENTRY-2264.003.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 "ALL" 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 "ALL" privilege in required input privileges to avoid elevate
> privilege by moving table cross DB
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[ https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511447#comment-16511447 ] 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 (v7.6.3#76005)
[jira] [Commented] (SENTRY-2264) It is possible to elevate privileges from DROP using alter table rename
[
https://issues.apache.org/jira/browse/SENTRY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509029#comment-16509029
]
Hadoop QA commented on SENTRY-2264:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12927391/SENTRY-2264.001.patch
against master.
{color:red}Overall:{color} -1 due to 7 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestOperationsPart1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart1
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/3874/console
This message is automatically generated.
> 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
>
>
> 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, INSERT, ALTER" at destination.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
