[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386358#comment-17386358
]
Aleksei Zotov edited comment on CASSANDRA-16404 at 7/23/21, 9:32 PM:
---------------------------------------------------------------------
[~samt]
Thanks for your input! I gave a thought to the command's syntax and here are
the details:
1. Such a function representation is currently supported (I tested that):
{code:java}
functions/ks/foo[Int32Type^DoubleType]{code}
I do not feel it is too heavy. However, I doubt operators are well familiar
with internal C* types. Fortunately, this piece of code
({{FunctionResource.fromName}} method) is not used anywhere and I feel we can
easily and safely switch from {{AbstractType}} to {{CQLType}} (I can raise and
handle a separate ticket for the sake of scope segregation).
2. Ideally we should support as many use cases as possible via CQL. For
example: for "data" resource we need a support of "ALL KEYSPACES", "KEYSPACE
ks1" and "KEYSPACE ks1 TABLE t1". If we do not support all possible
combinations then the invalidation becomes useless because currently we do not
support "recursive permissions invalidation", i.e. if a user has "KEYSPACE ks1"
permission then invalidation of "ALL KEYSPACES" won't delete this permission.
The same is applicable to functions. With that being said, I believe we cannot
skip/ignore invalidation of permissions on specific functions.
3. Here are the parameters we need to support:
* "\-\-all-keyspaces" / "\-\-keyspace ks1" / "\-\-keyspace ks1 \-\-table t1"
* "\-\-all-roles" / "\-\-role role1"
* "\-\-all-functions" / "\-\-functions-in-keyspace ks1" /
"\-\-functions-in-keyspace ks1 \-\-function foo[Int32Type^DoubleType]"
* "\-\-all-mbeans" / "\-\-mbean org.apache.cassandra.auth:type=*"
4. On the one hand, it is a bit awkward to support all these parameters. On
the other hand, the only alternative way (that I considered) is to add a proper
description to the CLI command with samples for different resource types. Based
on the examples operators could easily construct a resource and execute the
command. Smth like:
{code:java}
- ALL KEYSPACES -> data
- KEYSPACE ks1 -> data/ks1
- ks1.t1 -> data/ks1/t1
- ALL ROLES -> roles
- ROLE other_role -> roles/other_role
- ALL FUNCTIONS IN KEYSPACE ks1 -> functions/ks1
- FUNCTION ks1.f1(int, double) -> functions/ks1/f1[Int32Type^DoubleType]
- ALL MBEANS -> mbean\n" +
- MBEAN 'org.apache.cassandra.auth:type=* ->
mbean/org.apache.cassandra.auth:type=*
{code}
However, "airline" (the lib that is used for work with CLI) does not support
multi-line descriptions: [https://github.com/airlift/airline/issues/30.] So I
rejected this approach.
Please, let me know your thoughts on the migration from {{AbstractType}} to
{{CQLType}} (item #1) and whether proposed parameters look good to you (item
#3).
was (Author: azotcsit):
[~samt]
Thanks for your input! I gave a thought to the command's syntax and here are
the details:
1. Such a function representation is currently supported (I tested that):
{code:java}
functions/ks/foo[Int32Type^DoubleType]{code}
I do not feel it is too heavy. However, I doubt operators are well familiar
with internal C* types. Fortunately, this piece of code
({{FunctionResource.fromName}} method) is not used anywhere and I feel we can
easily and safely switch from {{AbstractType}} to {{CQLType}} (I can raise and
handle a separate ticket for the sake of scope segregation).
2. Ideally we should support as many use cases as possible via CQL. For
example: for "data" resource we need a support of "ALL KEYSPACES", "KEYSPACE
ks1" and "KEYSPACE ks1 TABLE t1". If we do not support all possible
combinations then the invalidation becomes useless because currently we do not
support "recursive permissions invalidation", i.e. if a user has "KEYSPACE ks1"
permission then invalidation of "ALL KEYSPACES" won't delete this permission.
The same is applicable to functions. With that being said, I believe we cannot
skip/ignore invalidation of permissions on specific functions.
3. Here are the parameters we need to support:
* "--all-keyspaces" / "--keyspace ks1" / "-keyspace ks1 --table t1"
* "--all-roles" / "–role role1"
* "--all-functions" / "--functions-in-keyspace ks1" / "--functions-in-keyspace
ks1 --function foo[Int32Type^DoubleType]"
* "--all-mbeans" / "–mbean org.apache.cassandra.auth:type=*"
4. On the one hand, it is a bit awkward to support all these parameters. On the
other hand, the only alternative way (that I considered) is to add a proper
description to the CLI command with samples for different resource types. Based
on the examples operators could easily construct a resource and execute the
command. Smth like:
{code:java}
- ALL KEYSPACES -> data
- KEYSPACE ks1 -> data/ks1
- ks1.t1 -> data/ks1/t1
- ALL ROLES -> roles
- ROLE other_role -> roles/other_role
- ALL FUNCTIONS IN KEYSPACE ks1 -> functions/ks1
- FUNCTION ks1.f1(int, double) -> functions/ks1/f1[Int32Type^DoubleType]
- ALL MBEANS -> mbean\n" +
- MBEAN 'org.apache.cassandra.auth:type=* ->
mbean/org.apache.cassandra.auth:type=*
{code}
However, "airline" (the lib that is used for work with CLI) does not support
multi-line descriptions: [https://github.com/airlift/airline/issues/30.] So I
rejected this approach.
Please, let me know your thoughts on the migration from {{AbstractType}} to
{{CQLType}} (item #1) and whether proposed parameters look good to you (item
#3).
> 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
