Details
Major Description
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.
Attachments
Issue Links
- is related to
-
KUDU-428 fine-grained authorization through Sentry integration
-
- Resolved
-