You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Andrew Wong (JIRA)" <ji...@apache.org> on 2019/03/05 06:09:00 UTC

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

Andrew Wong created KUDU-2729:
---------------------------------

             Summary: 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


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)