[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379900#comment-17379900
]
Sam Tunnicliffe commented on CASSANDRA-16404:
---------------------------------------------
I feel that the {{invalidatepermissionscache}} nodetool command could use a
little syntactic sugar as operators have
previously not had any reason to be aware of the resource hierarchy. Perhaps as
a first option we could support invalidation of all permissions for a supplied
user, with the option to specify resources when required.
That said, the format of resource names is not something I'd expect most
operators to be familiar with. So while
allowing a qualified resource name is good, perhaps we ought to base the cli
syntax more closely on CQL GRANT/REVOKE
statements. e.g.:
{code}bin/nodetool invalidatepermissionscache -u <username> [ -k <keyspace> |
-t <table> | -f <function> | -m
<mbean> | -r <role>] {code}
Stepping back a bit... I appreciate that a lot of effort has already gone into
this ticket, but I wonder if we ought to
approach this slightly differently. Nodetool is, to some extent, deprecated,
with access to system information via CQL &
virtual tables being the preferred alternative. Perhaps we would be better off
implementing this feature with a set of
virtual tables to represent the caches.
{code}
cqlsh:system_views> SELECT * FROM permissions_cache;
role | resource | permissions
---------+-------------------------+----------------------
user_a | data/test_ks/test_table | {'SELECT', 'MODIFY'}
cqlsh:system_views> SELECT * FROM network_permissions_cache;
role | datacenters
---------+--------------------
user_a | {'dc1', 'dc2'}
user_b | {}
{code}
The wrinkle I see would be in restricting the set of modifications permitted
against the virtual tables. i.e. A user,
with the requisite permissions, should be able to DELETE from and TRUNCATE a
*_cache table, but not perform any INSERT
or UPDATE modifications. It would require some special casing probably along
the lines of what we have in
{{ClientState::preventSystemKSSchemaModification}} but I don't think that would
be too onerous. Seeing as this is
targetting 4.x it seems slightly wrong to be adding brand new nodetool/JMX
operations.
> 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: Aleksei Zotov
> Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> 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
