[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17383381#comment-17383381
]
Sam Tunnicliffe edited comment on CASSANDRA-16404 at 7/19/21, 2:45 PM:
-----------------------------------------------------------------------
bq. Sam Tunnicliffe Does that sound reasonable to you?
Yes SGTM, thanks
[~azotcsit] I think it's only {{invalidatepermissionscache}} that warrants any
syntax change.
bq. "-u" might be bit confusing
You're right, I had overlooked that when sketching out that syntax.
Fortunately, we don't really need the {{-u}} flag as I think we can assume that
the non-option argument is the grantee, which is consistent with the other
commands anyway.
bq. if we do not have enough information from input to construct "Resource"
then we'll have to iterate through all cached records because "Resource" is a
part of key
I'd be tempted to enforce that through validation in the tool itself, although
iterating on the server side would still be required to invalidate all
parmissions for a user. So for instance, an invocation like this should be
rejected:
{code} bin/nodetool invalidatepermissionscache user_a -t some_table {code}
With the correct version being:
{code} bin/nodetool invalidatepermissionscache user_a -k some_keyspace -t
some_table {code}
Handling function resources is going to be a bit ugly as the arg types are
significant and so need to be included. The CQL representation is nicer for
the user but not very shell friendly whereas the internal representation is
very verbose. e.g. for a function with 2 int args:
{code} function ks.foo(int, int)
functions/ks/foo[org.apache.cassandra.db.marshal.Int32Type^org.apache.cassandra.db.marshal.Int32Type]
{code}
Seeing as we probably want a way to represent "all functions in a given
keyspace" anyway, maybe we should simplify and just make that the only option.
i.e. don't allow invalidation of permissions on specific functions, only all
functions in a particular keyspace.
What does everyone think?
was (Author: beobal):
bq. Sam Tunnicliffe Does that sound reasonable to you?
Yes SGTM, thanks
[~azotcsit] I think it's only {{invalidatepermissionscache}} that warrants any
syntax change.
bq. "-u" might be bit confusing
You're right, I had overlooked that when sketching out that syntax. , we don't
really need the {{-u}} flag as I think we can assume that the non-option
argument is the grantee, which is consistent with the other commands anyway.
bq. if we do not have enough information from input to construct "Resource"
then we'll have to iterate through all cached records because "Resource" is a
part of key
I'd be tempted to enforce that through validation in the tool itself, although
iterating on the server side would still be required to invalidate all
parmissions for a user. So for instance, an invocation like this should be
rejected:
{code} bin/nodetool invalidatepermissionscache user_a -t some_table {code}
With the correct version being:
{code} bin/nodetool invalidatepermissionscache user_a -k some_keyspace -t
some_table {code}
Handling function resources is going to be a bit ugly as the arg types are
significant and so need to be included. The CQL representation is nicer for
the user but not very shell friendly whereas the internal representation is
very verbose. e.g. for a function with 2 int args:
{code} function ks.foo(int, int)
functions/ks/foo[org.apache.cassandra.db.marshal.Int32Type^org.apache.cassandra.db.marshal.Int32Type]
{code}
Seeing as we probably want a way to represent "all functions in a given
keyspace" anyway, maybe we should simplify and just make that the only option.
i.e. don't allow invalidation of permissions on specific functions, only all
functions in a particular keyspace.
What does everyone think?
> 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
