[jira] [Assigned] (SENTRY-2300) Move Permission Update due to DDL to HMS Post Event Listener

["Arjun Mishra (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SENTRY-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arjun Mishra reassigned SENTRY-2300:
------------------------------------

    Assignee: Arjun Mishra  (was: Na Li)

> Move Permission Update due to DDL to HMS Post Event Listener
> ------------------------------------------------------------
>
>                 Key: SENTRY-2300
>                 URL: https://issues.apache.org/jira/browse/SENTRY-2300
>             Project: Sentry
>          Issue Type: Bug
>          Components: Sentry
>    Affects Versions: 2.1.0
>            Reporter: Na Li
>            Assignee: Arjun Mishra
>            Priority: Major
>
> There was a code in MetastorePlugin that modified Sentry privileges on table Create/Drop and database Create/Drop. As part of Sentry HA work we moved all this logic from Sentry plugin to be driven by notifications which required the extra synchronization between HMS and Sentry.
> It should be possible to do permission changes in the post event listener itself to avoid blocking for Sentry. This requires some experiments though because it may cause strange artifacts since at the time these DDL operations are done Sentry may not be aware of the current state - for example you may try to change permissions of a table that Sentry doesn’t know about, which seems to be OK. 
> This update will have the following benefits:
> {code}
> * HMS waits on Sentry polling HMS update takes 0.5 to 1 second. This update will remove this delay
> * Sentry knows every DDL update, and therefore can update permission correctly. In current approach using notification processing, Sentry could miss updates if full snapshot is fetched from HMS, and permission is not updated correctly. In the case of table rename, when mission DDL update event because of full snapshot, sentry will not move the permissions associated with old table to the new table. And the authorization on queries on the renamed table will fail.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)