[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326113#comment-17326113 ]
Alexey Zotov edited comment on CASSANDRA-16404 at 4/20/21, 9:37 PM: -------------------------------------------------------------------- [~blerer] [~sumanth.pasupuleti] Thanks for the feedback! I've addressed your comments. I'll push refactoring for {{NodeTool}} tests that are not related to the invalidation into a separate PR. Basically I'm done with the changes I wanted to make. Could you, please, review the changes. I read about [roles hierarchy|https://www.datastax.com/blog/role-based-access-control-cassandra] and I feel it would be complicated enough to support them. Basically the problem is related to the fact that we cache permissions (permissions, network permissions, jmx permissions) after we calculate them using roles hierarchy. Permissions invalidation for a user (a role with "login" attribute = true) works fine with the current changes. However, permissions invalidation for a group role (a role that is granted to other roles) would require tracing the hierarchy in a reverse direction and invalidating the whole affected hierarchy from cache. It is theoretically possible, but in practice there is one directional relation between roles ({{RolesCache extends AuthCache<RoleResource, Set<Role>>}}). I can take a look to this part further if you believe that it needs to be address at this point, also I'd be glad to hear a piece of advice on the best way to tackle the hierarchical invalidation. was (Author: azotcsit): [~blerer] [~sumanth.pasupuleti] Thanks for the feedback! I've addressed your comments. I'll push tests refactoring into a separate PR. Basically I'm done with the changes I wanted to make. Could you, please, review the changes. I read about [roles hierarchy|https://www.datastax.com/blog/role-based-access-control-cassandra] and I feel it would be complicated enough to support them. Basically the problem is related to the fact that we cache permissions (permissions, network permissions, jmx permissions) after we calculate them using roles hierarchy. Permissions invalidation for a user (a role with "login" attribute = true) works fine with the current changes. However, permissions invalidation for a group role (a role that is granted to other roles) would require tracing the hierarchy in a reverse direction and invalidating the whole affected hierarchy from cache. It is theoretically possible, but in practice there is one directional relation between roles ({{RolesCache extends AuthCache<RoleResource, Set<Role>>}}). I can take a look to this part further if you believe that it needs to be address at this point, also I'd be glad to hear a piece of advice on the best way to tackle the hierarchical invalidation. > Provide a nodetool way of invalidating auth caches > -------------------------------------------------- > > Key: CASSANDRA-16404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16404 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization > Reporter: Sumanth Pasupuleti > Assignee: Alexey Zotov > Priority: Normal > Fix For: 4.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > We currently have nodetool commands to invalidate certain caches like > KeyCache, RowCache and CounterCache. > Being able to invalidate auth caches as well can come in handy in situations > where, critical backend auth changes may need to be in effect right away for > all the connections, especially in configurations where cache validity is > chosen to be for a longer duration. An example can be that an authenticated > user "User1" is no longer authorized to access a table resource "table1" and > it is vital that this change is reflected right away, without having to wait > for cache expiry/refresh to trigger. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org