[jira] [Resolved] (KUDU-2729) Consider refreshing authorization metadata upon altering tables

["Andrew Wong (JIRA)" <ji...@apache.org>]

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

Andrew Wong resolved KUDU-2729.
-------------------------------
       Resolution: Not A Problem
    Fix Version/s: n/a

After some discussion with Adar and looking through client-side AlterTable behavior, it seems this isn't an issue because an AlterTable operation doesn't update the client-side schema, i.e. there must be an OpenTable to follow the AlterTable if the client were to use any newly added columns.

If a privilege exists in the external authorization metadata service (e.g. Sentry) for the new column before the AlterTable operation is performed, the subsequent OpenTable required to operate with new columns will reflect privileges on this new column.

If a privilege _doesn't_ exist for the new column before the AlterTable operation is performed, there isn't much we can do. An operator should contact the authorization service admin to add the privilege, and once done, and one a new token is generated based on these new privileges, the Kudu user should be able to access the new column.

In any case, I'm resolving this as not an issue; the ticket assumes that AlterTable does the equivalent of OpenTable in exposing the new column (and thus would need to get a new token as well), which doesn't appear to be true.

> Consider refreshing authorization metadata upon altering tables
> ---------------------------------------------------------------
>
>                 Key: KUDU-2729
>                 URL: https://issues.apache.org/jira/browse/KUDU-2729
>             Project: Kudu
>          Issue Type: Improvement
>          Components: client, master, security
>            Reporter: Andrew Wong
>            Priority: Major
>             Fix For: n/a
>
>
> The KUDU-428 design doc doesn't touch on the impact of altering table schemas. Tokens and privileges don’t currently get refreshed upon altering a table, which could eventually lead to unintuitive behavior. Take the following series of events:
>  # Get a token that authorizes the client for some columns of a table
>  # Client adds a column and waits for it to complete
>  ## It doesn’t get a new authz token because the token hasn’t expired
>  # It tries to scan from the column that it just created
>  # This fails because the token doesn’t have the privilege for that column
>  ## As implemented, this is a fatal authorization error and the scan will not be retried -- the expectation being that privileges are relatively static, and that if you don’t have the privileges, trying to refresh your privilege will not help
>  # The client must OpenTable to get a newer token
> This will happen _even if_ the user has permissions on that column. This is a poor user experience. Some solutions?
>  * Invalidate master-side privilege cache every time we complete an alter table.
>  * Similarly, send a new token alongside responses to a successful IsAlterTableDone.
> Now what if the user _didn’t_ have permissions on that column because they didn’t add the privileges in Sentry yet? The above solution would not work (i.e. a new token wouldn't help because the privileges in Sentry wouldn't reflect the new column). Some solutions?
>  * The user is forced to wait until the privileges are added in Sentry, and then for the privileges in the cache to expire, and then OpenTable().
>  * Alternatively, user must have _all_ scan privileges on the table.



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