[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] [Created] (SENTRY-2280) The request received in SentryPolicyStoreProcessor.sentry_notify_hms_event is null
Na Li created SENTRY-2280: - Summary: The request received in SentryPolicyStoreProcessor.sentry_notify_hms_event is null Key: SENTRY-2280 URL: https://issues.apache.org/jira/browse/SENTRY-2280 Project: Sentry Issue Type: Bug Components: Sentry Affects Versions: 2.1.0 Reporter: Na Li Assignee: Na Li When running e2e test TestDbPrivilegeCleanupOnDrop.testRenameTablesWithinDBSinglePrivilege, I found the request received in SentryPolicyStoreProcessor.sentry_notify_hms_event is null There are multiple issues in fix from "SENTRY-2243: Extend the thrift definition for policy service to learn owner information" 1. The exception was thrown because the protocol_version was not set 2. TSentryAuthorizable.server was not set 3. TSentryHmsEventNotification.ownerType and ownerName are not set for table rename event As a result, the request received by server is null since thrift at server side cannot re-construct a valid request of type TSentryHmsEventNotification Once we fix the above issues, we need to make sure SentryPolicyStoreProcessor.sentry_notify_hms_event does not transfer owner in "alter table rename" event. -- 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] [Updated] (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:all-tabpanel ] Na Li updated SENTRY-2264: -- Attachment: SENTRY-2264.004.patch > 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] [Updated] (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:all-tabpanel ] Na Li updated SENTRY-2264: -- Attachment: SENTRY-2264.004.patch > 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-2269) Make SentryStore pluggable
[
https://issues.apache.org/jira/browse/SENTRY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523105#comment-16523105
]
kalyan kumar kalvagadda commented on SENTRY-2269:
-
[~fahdsiddiqui] Thanks for the contribution.
> Make SentryStore pluggable
> --
>
> Key: SENTRY-2269
> URL: https://issues.apache.org/jira/browse/SENTRY-2269
> Project: Sentry
> Issue Type: Improvement
> Components: sentrystore
>Affects Versions: 2.1.0
>Reporter: Fahd Siddiqui
>Assignee: Fahd Siddiqui
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: SENTRY-2269.1.patch
>
>
> Make SentryStore pluggable so a different implementation can be plugged in at
> run-time using a config property ("sentry.service.sentrystore"), similar to
> what we have for processor factories.
> This would entail extracting all public methods of SentryStore to a
> SentryStoreInterface and converting all call sites to program to the
> interface.
> It will default to the existing SentryStore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SENTRY-2269) Make SentryStore pluggable
[
https://issues.apache.org/jira/browse/SENTRY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kalyan kumar kalvagadda updated SENTRY-2269:
Resolution: Fixed
Fix Version/s: 2.1.0
Status: Resolved (was: Patch Available)
> Make SentryStore pluggable
> --
>
> Key: SENTRY-2269
> URL: https://issues.apache.org/jira/browse/SENTRY-2269
> Project: Sentry
> Issue Type: Improvement
> Components: sentrystore
>Affects Versions: 2.1.0
>Reporter: Fahd Siddiqui
>Assignee: Fahd Siddiqui
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: SENTRY-2269.1.patch
>
>
> Make SentryStore pluggable so a different implementation can be plugged in at
> run-time using a config property ("sentry.service.sentrystore"), similar to
> what we have for processor factories.
> This would entail extracting all public methods of SentryStore to a
> SentryStoreInterface and converting all call sites to program to the
> interface.
> It will default to the existing SentryStore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2238) Explicitly set Database on SentryHivePrivilegeObjectDesc
[
https://issues.apache.org/jira/browse/SENTRY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523080#comment-16523080
]
Hadoop QA commented on SENTRY-2238:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12929113/SENTRY-2238.02.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/3922/console
This message is automatically generated.
> Explicitly set Database on SentryHivePrivilegeObjectDesc
> -
>
> Key: SENTRY-2238
> URL: https://issues.apache.org/jira/browse/SENTRY-2238
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: SENTRY-2238.001.patch, SENTRY-2238.01.patch,
> SENTRY-2238.02.patch
>
>
> Right now database is not supported with command SHOW GRANT ROLE/USER ON
> DATABASE
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SENTRY-2238) Explicitly set Database on SentryHivePrivilegeObjectDesc
[ https://issues.apache.org/jira/browse/SENTRY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arjun Mishra updated SENTRY-2238: - Attachment: SENTRY-2238.02.patch > Explicitly set Database on SentryHivePrivilegeObjectDesc > - > > Key: SENTRY-2238 > URL: https://issues.apache.org/jira/browse/SENTRY-2238 > Project: Sentry > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Arjun Mishra >Assignee: Arjun Mishra >Priority: Major > Fix For: 2.1.0 > > Attachments: SENTRY-2238.001.patch, SENTRY-2238.01.patch, > SENTRY-2238.02.patch > > > Right now database is not supported with command SHOW GRANT ROLE/USER ON > DATABASE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SENTRY-2238) Explicitly set Database on SentryHivePrivilegeObjectDesc
[ https://issues.apache.org/jira/browse/SENTRY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arjun Mishra updated SENTRY-2238: - Summary: Explicitly set Database on SentryHivePrivilegeObjectDesc (was: Add support for DATABASE in show grant on command) > Explicitly set Database on SentryHivePrivilegeObjectDesc > - > > Key: SENTRY-2238 > URL: https://issues.apache.org/jira/browse/SENTRY-2238 > Project: Sentry > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Arjun Mishra >Assignee: Arjun Mishra >Priority: Major > Fix For: 2.1.0 > > Attachments: SENTRY-2238.001.patch, SENTRY-2238.01.patch > > > Right now database is not supported with command SHOW GRANT ROLE/USER ON > DATABASE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Na Li updated SENTRY-2264: -- Description: 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 was: 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 "select" privilege in required input privileges > 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] [Updated] (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:all-tabpanel ] Na Li updated SENTRY-2264: -- Description: 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 "select" privilege in required input privileges was: 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 > 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 "select" privilege in required input privileges -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Na Li updated SENTRY-2264: -- Attachment: SENTRY-2264.003.patch > 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 "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-2269) Make SentryStore pluggable
[
https://issues.apache.org/jira/browse/SENTRY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522430#comment-16522430
]
kalyan kumar kalvagadda commented on SENTRY-2269:
-
[~fahdsiddiqui] When you submit new patch with a change please update the
version of the patch "SENTRY-2269.X.patch". It will help in tracking stuff.
> Make SentryStore pluggable
> --
>
> Key: SENTRY-2269
> URL: https://issues.apache.org/jira/browse/SENTRY-2269
> Project: Sentry
> Issue Type: Improvement
> Components: sentrystore
>Affects Versions: 2.1.0
>Reporter: Fahd Siddiqui
>Assignee: Fahd Siddiqui
>Priority: Major
> Attachments: SENTRY-2269.1.patch
>
>
> Make SentryStore pluggable so a different implementation can be plugged in at
> run-time using a config property ("sentry.service.sentrystore"), similar to
> what we have for processor factories.
> This would entail extracting all public methods of SentryStore to a
> SentryStoreInterface and converting all call sites to program to the
> interface.
> It will default to the existing SentryStore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2269) Make SentryStore pluggable
[
https://issues.apache.org/jira/browse/SENTRY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522428#comment-16522428
]
kalyan kumar kalvagadda commented on SENTRY-2269:
-
[~akolb] I see you had some comments in Jira. Do you want to review thew patch?
If yes, I will wait for you before pushing the changes upstream.
> Make SentryStore pluggable
> --
>
> Key: SENTRY-2269
> URL: https://issues.apache.org/jira/browse/SENTRY-2269
> Project: Sentry
> Issue Type: Improvement
> Components: sentrystore
>Affects Versions: 2.1.0
>Reporter: Fahd Siddiqui
>Assignee: Fahd Siddiqui
>Priority: Major
> Attachments: SENTRY-2269.1.patch
>
>
> Make SentryStore pluggable so a different implementation can be plugged in at
> run-time using a config property ("sentry.service.sentrystore"), similar to
> what we have for processor factories.
> This would entail extracting all public methods of SentryStore to a
> SentryStoreInterface and converting all call sites to program to the
> interface.
> It will default to the existing SentryStore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SENTRY-2056) Display test-patch.py output on the standard console to see progress on Jenkins
[ https://issues.apache.org/jira/browse/SENTRY-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-2056: Resolution: Fixed Fix Version/s: 2.1.0 Status: Resolved (was: Patch Available) Committed changes to show the logs in the console. > Display test-patch.py output on the standard console to see progress on > Jenkins > --- > > Key: SENTRY-2056 > URL: https://issues.apache.org/jira/browse/SENTRY-2056 > Project: Sentry > Issue Type: Task > Components: Sentry >Affects Versions: 2.1.0 >Reporter: Sergio Peña >Assignee: kalyan kumar kalvagadda >Priority: Major > Fix For: 2.1.0 > > Attachments: SENTRY-2056.001.patch, SENTRY-2056.003.patch, > SENTRY-2056.1.patch, SENTRY-2056.2.patch > > > The test-patch.py is used by Jenkins to build and test the sentry code. This > patch currently sends the output to some artifact files that Jenkins show > once the job finished. > We should send the output to the console as well to see the current progress > of the Jenkins job console. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SENTRY-2257) Implement Sentry store API's to update owner privilege on a authorizable
[ https://issues.apache.org/jira/browse/SENTRY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-2257: Resolution: Fixed Status: Resolved (was: Patch Available) Fox for this issue is part of SENTRY-2274 > Implement Sentry store API's to update owner privilege on a authorizable > > > Key: SENTRY-2257 > URL: https://issues.apache.org/jira/browse/SENTRY-2257 > Project: Sentry > Issue Type: Bug > Components: Sentry >Affects Versions: 2.1.0 >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda >Priority: Major > Fix For: 2.1.0 > > Attachments: SENTRY-2257.001.patch, SENTRY-2257.002.patch, > SENTRY-2257.003.patch, SENTRY-2257.004.patch, SENTRY-2257.005.patch, > SENTRY-2257.006.patch > > > Implement functionality in sentry store to update owner privilege on an > authorizable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SENTRY-2241) Extend the Sync Listener to pass owner information to sentry server.
[ https://issues.apache.org/jira/browse/SENTRY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-2241: Resolution: Fixed Fix Version/s: 2.1.0 Status: Resolved (was: Patch Available) Fix for this issue is part of SENTRY-2274 and SENTRY-2275. > Extend the Sync Listener to pass owner information to sentry server. > > > Key: SENTRY-2241 > URL: https://issues.apache.org/jira/browse/SENTRY-2241 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: 2.1.0 >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda >Priority: Major > Fix For: 2.1.0 > > Attachments: SENTRY-2241.001.patch, SENTRY-2241.004.patch, > SENTRY-2241.005.patch, SENTRY-2241.006.patch > > > Sentry has SentrySyncHMSNotificationsPostEventListener which is added a post > listener in HMS. This listener should be extended to get the owner > information of tables and databases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SENTRY-2279) Make debugging easy for HDFS-sync.
[ https://issues.apache.org/jira/browse/SENTRY-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda updated SENTRY-2279: Description: # Add logs to console and also audit logs for below events ## Why HMS snapshot is taken. ## HMS full snapshot is fetched. ## HMS Full snapshot is persisted. ## Fetching full Update from sentry for Namenode. ## Full update is sent to Namenode. ## HDFS ACL are synchronization is complete. # Show thread information in logs. This makes debugging easy. # Add a mechanism to track where sentry is in process of fetching Full Snapshot. ## Adding metrics which capture the current state ## Adding logs with intermediate states is also an option. # Make logs related to HDFS-ACL synchronization more verbose. ## This includes adding more logging. ## Elevate the logs level from “DEBUG” to “INFO” for some of the log messages. was: # Add logs to console and also audit logs for below events # Why HMS snapshot is taken. # HMS full snapshot is fetched. # HMS Full snapshot is persisted. # Fetching full Update from sentry for Namenode. # Full update is sent to Namenode. # HDFS ACL are synchronization is complete. # Show thread information in logs. This makes debugging easy. # Add a mechanism to track where sentry is in process of fetching Full Snapshot. # Adding metrics which capture the current state # Adding logs with intermediate states is also an option. # Make logs related to HDFS-ACL synchronization more verbose. # This includes adding more logging. # Elevate the logs level from “DEBUG” to “INFO” for some of the log messages. > Make debugging easy for HDFS-sync. > -- > > Key: SENTRY-2279 > URL: https://issues.apache.org/jira/browse/SENTRY-2279 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Affects Versions: 2.1.0 >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda >Priority: Major > > # Add logs to console and also audit logs for below events > ## Why HMS snapshot is taken. > ## HMS full snapshot is fetched. > ## HMS Full snapshot is persisted. > ## Fetching full Update from sentry for Namenode. > ## Full update is sent to Namenode. > ## HDFS ACL are synchronization is complete. > # Show thread information in logs. This makes debugging easy. > # Add a mechanism to track where sentry is in process of fetching Full > Snapshot. > ## Adding metrics which capture the current state > ## Adding logs with intermediate states is also an option. > # Make logs related to HDFS-ACL synchronization more verbose. > ## This includes adding more logging. > ## Elevate the logs level from “DEBUG” to “INFO” for some of the log > messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SENTRY-2279) Make debugging easy for HDFS-sync.
[ https://issues.apache.org/jira/browse/SENTRY-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda reassigned SENTRY-2279: --- Assignee: kalyan kumar kalvagadda > Make debugging easy for HDFS-sync. > -- > > Key: SENTRY-2279 > URL: https://issues.apache.org/jira/browse/SENTRY-2279 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Affects Versions: 2.1.0 >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda >Priority: Major > > # Add logs to console and also audit logs for below events > # Why HMS snapshot is taken. > # HMS full snapshot is fetched. > # HMS Full snapshot is persisted. > # Fetching full Update from sentry for Namenode. > # Full update is sent to Namenode. > # HDFS ACL are synchronization is complete. > # Show thread information in logs. This makes debugging easy. > # Add a mechanism to track where sentry is in process of fetching Full > Snapshot. > # Adding metrics which capture the current state > # Adding logs with intermediate states is also an option. > # Make logs related to HDFS-ACL synchronization more verbose. > # This includes adding more logging. > # Elevate the logs level from “DEBUG” to “INFO” for some of the log messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SENTRY-2279) Make debugging easy for HDFS-sync.
kalyan kumar kalvagadda created SENTRY-2279: --- Summary: Make debugging easy for HDFS-sync. Key: SENTRY-2279 URL: https://issues.apache.org/jira/browse/SENTRY-2279 Project: Sentry Issue Type: Improvement Components: Sentry Affects Versions: 2.1.0 Reporter: kalyan kumar kalvagadda # Add logs to console and also audit logs for below events # Why HMS snapshot is taken. # HMS full snapshot is fetched. # HMS Full snapshot is persisted. # Fetching full Update from sentry for Namenode. # Full update is sent to Namenode. # HDFS ACL are synchronization is complete. # Show thread information in logs. This makes debugging easy. # Add a mechanism to track where sentry is in process of fetching Full Snapshot. # Adding metrics which capture the current state # Adding logs with intermediate states is also an option. # Make logs related to HDFS-ACL synchronization more verbose. # This includes adding more logging. # Elevate the logs level from “DEBUG” to “INFO” for some of the log messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
