[jira] [Created] (CASSANDRA-17016) Allow reverse iteration of resources during permissions checking

["Josh McKenzie (Jira)" <ji...@apache.org>]

Josh McKenzie created CASSANDRA-17016:
-----------------------------------------

             Summary: Allow reverse iteration of resources during permissions checking
                 Key: CASSANDRA-17016
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17016
             Project: Cassandra
          Issue Type: Improvement
          Components: Feature/Authorization
            Reporter: Josh McKenzie
            Assignee: Josh McKenzie


When we perform authz checks for AuthenticatedUser on a given resource, we traverse the resource hierarchy until we either find the required permission or we exhaust the traversal. This goes from most specific resource (i.e. iResource we're interested in) to the broadest (the root for that iResource type).

Since permissions are a whitelist it isn't possible for a permission granted on a more specific resource to be negated or overridden by a grant on a resource lower in the hierarchy towards the root. For example, for DataResource, the hierarchy goes:
{code:java}
root -> keyspace -> table{code}
So for instance if we:

 
{code:java}
GRANT ALL ON KEYSPACE ks TO admin_user; 
{code}
 It is impossible to grant admin_user any set of permissions more restrictive than ALL on ks.

When a request comes in for a user with permissions on a ks for example, you can have a path of:
 # Validate SELECT on t1
 # Then check for SELECT on ks
 # Then check for permissions on 'root'

These unnecessary lookups can negate some of the benefits of caching (and pre-warming, which another ticket is in flight for), and lead to issues on bounces with timeouts.

Additionally, the permissions cache ends up storing far more entries than necessary, as a subsequent request for ks.t2 by user_x will go through the same process and create a second cache entry etc.

So all this said - this is something we should allow operators to opt-in to; impact and performance is going to be highly dependent on the pattern of authentication granting and usage on a cluster.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org