[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409375#comment-17409375 ] Aleksei Zotov commented on CASSANDRA-16404: --- I raised CASSANDRA-16914 to implement Virtual Tables for Auth Caches. > 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.1 > > Time Spent: 1h 40m > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409342#comment-17409342 ] Aleksei Zotov commented on CASSANDRA-16404: --- Great, thanks a lot for your support [~samt]! > 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.1 > > Time Spent: 1h > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409013#comment-17409013 ] Sam Tunnicliffe commented on CASSANDRA-16404: - [~azotcsit], I was and it looks good to me. Apologies for both the long wait and the typo, I've rebased and launched CI runs and commit both the patch and test when those complete. ||branch||dtest||Circle CI||Apache CI|| |[16404-trunk|https://github.com/beobal/cassandra/tree/16404-trunk]|[16404|https://github.com/beobal/cassandra-dtest/tree/16404]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16404-trunk]|[apache|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1093] > 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: 1h > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407244#comment-17407244 ] Aleksei Zotov commented on CASSANDRA-16404: --- [~samt] Were you able to check the dtest? > 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: 1h > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17402817#comment-17402817 ] Aleksei Zotov commented on CASSANDRA-16404: --- [~samt] I wrote a dtest for JMX auth cache. Could you please take a look to [https://github.com/apache/cassandra-dtest/pull/154]? Apart from the changes I specified in the description, I had updated your commit's message (I fixed a typo in my name). > 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: 1h > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401041#comment-17401041 ] Sam Tunnicliffe commented on CASSANDRA-16404: - bq. I see 4 failures, but they do not seem to be related to these changes. Yep, LGTM too. Good stuff! bq. Am I right that currently there are no dtests for JMXPermissionsCache/JmxPermissionsCache MBeans? Shall I try to come up with a test for that (basically I'd like to get familiar with dtests)? Can I use this ticket or need to create another one? Yes, you are correct there, so feel free to use this as an opportunity to get comfortable with dtests. Seeing as this isn't an urgent issue, I'd say it's fine to take our time adding new tests here rather than opening another Jira. If you create a dtest branch based off mine, just open a PR against trunk with it when you're ready and I'll review/merge there. If you have any questions, just ask. bq. It needs to be renamed to match the class name. d'oh, good catch. Fixed in my branch. > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400607#comment-17400607
]
Aleksei Zotov commented on CASSANDRA-16404:
---
[~samt]
Great, thanks for taking care of that! I see 4 failures, but they do not seem
to be related to these changes.
I checked your branch for dtest repo and can see the change for handling
NetworkPermissionsCache/NetworkAuthCache MBeans. Am I right that currently
there are no dtests for JMXPermissionsCache/JmxPermissionsCache MBeans? Shall I
try to come up with a test for that (basically I'd like to get familiar with
dtests)? Can I use this ticket or need to create another one?
===
Also I think there is a small issue with the last change:
{code:java}
public static final String CACHE_NAME = "JMXPermissionsCache";
@Deprecated
public static final String DEPRECATED_CACHE_NAME = "JmxPermissionsCache";
{code}
it should be opposite:
{code:java}
public static final String CACHE_NAME = "JmxPermissionsCache";
@Deprecated
public static final String DEPRECATED_CACHE_NAME = "JMXPermissionsCache";
{code}
JMXPermissionsCache is what we have currently
([https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/jmx/AuthorizationProxy.java#L483]).
It needs to be renamed to match the class name.
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400403#comment-17400403
]
Sam Tunnicliffe commented on CASSANDRA-16404:
-
Rather than going back to the old bean names, we have a precedent of aliasing
and deprecating them. I've pushed a additional commit to my branch which fixes
the original test failure in this way. I've also extended the dtest to cover
both the old and new bean name (for {{NetworkAuthTest}} only, it didn't seem
worth adding new tests for the JMX cache just for this).
Also (temporarily) modified circle config to use my own dtest branch & started
a new apache ci job
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1032]
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398255#comment-17398255
]
Aleksei Zotov commented on CASSANDRA-16404:
---
Thanks [~samt]! I checked the build and mentioned a few failures related to the
renaming of {{NetworkAuthCache}} MBean. I fixed that and additionally
incorporated your change on the error message
([db917dfe04ffdf0cda393474dce431d749e7bded|https://github.com/apache/cassandra/pull/950/commits/db917dfe04ffdf0cda393474dce431d749e7bded]).
Also I rebased and squashed the changes into
[https://github.com/alex-ninja/cassandra/tree/cassandra-16404-trunk] branch (I
intentionally do not want to squash commits in the PR branch and keep them for
historical reference), so it is easy to kick off the CI again.
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398082#comment-17398082 ] Sam Tunnicliffe commented on CASSANDRA-16404: - Thanks [~azotcsit], looks good to me. I've squashed & rebased, with one tiny tweak to the new error message, and kicked off CI runs. Assuming they look good, I'll commit when they're done. ||branch||Circle CI||Apache CI|| |[16404-trunk|https://github.com/beobal/cassandra/tree/16404-trunk]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16404-trunk]|[apache|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1011] > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17387622#comment-17387622 ] Aleksei Zotov commented on CASSANDRA-16404: --- [~samt] Good catch! I added a try-catch and a corresponding test. Please, let me know if you see any other points for improvement. > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17387348#comment-17387348
]
Sam Tunnicliffe commented on CASSANDRA-16404:
-
bq. role_permissions table relies on this method while storing existing
permissions. So we cannot easily change it
this is correct. The only way around it would be to accept a CQL format string
and parse it on the server, but to be honest I don't believe it's really worth
it. So I'd say we should stick with the internal representation for now, seeing
as it's very much a poweruser feature anyway.
That one niggle aside, the CLI looks pretty good to me. There's just one small
issue whereby supplying invalid types for function params throws an exception,
which we could catch and present more nicely.
{code}
❯ bin/nodetool invalidatepermissionscache --functions-in-keyspace foo
--function bar\[x^y\] user
error: org.apache.cassandra.db.marshal.x
-- StackTrace --
java.lang.ClassNotFoundException: org.apache.cassandra.db.marshal.x
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at
org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:716)
at
org.apache.cassandra.db.marshal.TypeParser.getAbstractType(TypeParser.java:357)
at org.apache.cassandra.db.marshal.TypeParser.parse(TypeParser.java:89)
at
org.apache.cassandra.auth.FunctionResource.argsListFromString(FunctionResource.java:338)
at
org.apache.cassandra.auth.FunctionResource.fromName(FunctionResource.java:190)
at org.apache.cassandra.auth.Resources.fromName(Resources.java:60)
at
org.apache.cassandra.auth.PermissionsCache.invalidatePermissions(PermissionsCache.java:48)
...
...
...
{code}
Otherwise, I think we're pretty much done with this. Thanks for all the good
work [~azotcsit]
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386915#comment-17386915
]
Aleksei Zotov commented on CASSANDRA-16404:
---
[~samt]
> 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).
That's not completely correct. Even though {{fromName}} is not used, it needs
to be aligned with {{getName}} which is used in a few places. I briefly checked
the usages of {{getName}} and looks like {{role_permissions}} table relies on
this method while storing existing permissions. So we cannot easily change it.
I made the change with introducing multiple CLI options. Please, review and let
me know if there are any improvement points.
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386358#comment-17386358
]
Aleksei Zotov commented on CASSANDRA-16404:
---
[~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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17383381#comment-17383381
]
Sam Tunnicliffe commented on CASSANDRA-16404:
-
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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17382085#comment-17382085
]
Aleksei Zotov commented on CASSANDRA-16404:
---
[~blerer]
The plan sounds good to me! I'd be glad to give a try to {{CASSANDRA-16806.}}
[~samt]
Do you want me to change the syntax for {{invalidatepermissionscache}} command
only or for all?
I'll think on other syntax in order to simplify operations. Just a couple of
thoughts:
# "-u" might be bit confusing because there is "(-u | --username
)" which is JMX user.
# 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 . It actually should not be a significant issue because there should not
be many records, but I just want to highlight that.
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381941#comment-17381941
]
Benjamin Lerer commented on CASSANDRA-16404:
[~azotcsit] What I would propose is to address Sam feedback and then commit the
patch as it does not make adding a Virtual Table more complicated than it was
before.
We can then open a patch for providing the same functionality through Virtual
Tables. I nobody takes it I will.
I opened {{CASSANDRA-16806}} to provide support for TRUNCATE statement on
Virtual Tables. Feel free to take it if you feel like it.
[~samt] Does that sound reasonable to you?
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380539#comment-17380539
]
Sam Tunnicliffe commented on CASSANDRA-16404:
-
Yep, I completely recognise your points here [~blerer], but I suppose my
general counter argument would be if not now, when?
{quote}I also want to raise the fact that so far the Virtual Tables that we
expose do not support updates. The mechanism is there but has not really been
used (TRUNCATE is not supported at at).
{quote}
This is a brand new, low risk feature which is not blocking a release and nor
is it particularly urgent. That seems to me to make it an ideal way to explore
& flesh out that area.
{quote}Will it not make sense to support both approach until Virtual Tables
provide the same level of functionalities that JMX and NodeTool or an extended
version?
{quote}
That is quite an ambitious goal. My concern is that if we take the approach of
splitting each task like this into distinct tickets, then pragmatism will get
the better of us as it has in the past. That is, the desire for something that
"does the job" today trumps the better/newer, but ultimately redundant, stuff.
i.e. if there's a way to acheive this through nodetool/JMX, the incentive to
build the VT version largely disappears.
All that said, like I said before I do appreciate that a lot of work has
already gone into this ticket so it's absolutely my bad for not bringing
forward this suggestion earlier. Aside from the syntactic stuff I mentioned in
my previous comment, this generally LGTM, so I certainly wouldn't dig my heels
in over it should we choose to stick with the current approach.
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380512#comment-17380512 ] Benjamin Lerer commented on CASSANDRA-16404: I agree that we would like to move away from JMX and Nodetool. Nevertheless, We never had some clear discussion around it and I imagine that they will still be there for several releases and I am wonder if having an hybride between the 2 approach is necessarily a good approach. I also want to raise the fact that so far the Virtual Tables that we expose do not support updates. The mechanism is there but has not really been used (TRUNCATE is not supported at at). Now, I really love your suggestion [~samt]. Will it not make sense to support both approach until Virtual Tables provide the same level of functionalities that JMX and NodeTool or an extended version? If yes, my suggestion would be to split the task in 2 (or more if some extra changes are needed in the Virtual Table framework). Finish the current patch and open a new ticket to provide the same functionality through some Virtual Tables. [~samt] What is your opinion? > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380401#comment-17380401 ] Sam Tunnicliffe commented on CASSANDRA-16404: - Thanks [~azotcsit], and apologies again for dropping in that suggestion so late. > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380069#comment-17380069 ] Aleksei Zotov commented on CASSANDRA-16404: --- [~samt] thanks for the detailed explanation! Virtual tables sound like a full re-work, but it is not a problem at all. It is a good chance to get familiar with them! I'll need some time to understand the details around virtual tables and the way to use them for caches. -If- Once I have some question, I'll get back to you. In the meantime, I'll move the ticket back to "IN PROGRESS". > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
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 [ -k |
-t | -f | -m
| -r ] {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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378427#comment-17378427
]
Aleksei Zotov commented on CASSANDRA-16404:
---
[~blerer]
Thanks for checking the code!
{quote}I did not realized that the JMX interface for that part of the code tend
to be nested within the implementation classes. So I would do the same despite
what I said earlier.
{quote}
I've given it a try and realized that it causes cyclic inheritance:
{code:java}
public class RolesCache implements RolesCache.RolesCacheMBean
{
...
public static interface RolesCacheMBean extends AuthCacheMBean
{
...
}
}
{code}
and it is not compiling.
Similar approach works for other caches because they have another structure:
{code:java}
public class SomeHolderClass
{
...
public static class RolesCache implements SomeClass.RolesCacheMBean
{
...
}
public static interface RolesCacheMBean extends AuthCacheMBean
{
...
}
}
{code}
I see the following potential ways to proceed:
1. keep everything as is - that's what I'm inclined to.
2. introduce "holder" classes (similarly like we have for other caches) - I do
not like it because it will lead to many changes (that we try to prevent
without a real need). Also such holder classes without additional logic look
weird and make not much sense.
3. having interface in the same file, but non-public, like:
{code:java}
public class RolesCache implements RolesCache.RolesCacheMBean
{
...
}
interface RolesCacheMBean extends AuthCacheMBean
{
...
}
{code}
also does not seem to be working because the interface definition should be
public to be available from {{NodeProbe}}.
I see no other obvious ways to have it simple and working other than the
current approach. Your suggestions will be much appreciated. Please, let me
know your thoughts.
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375378#comment-17375378 ] Sam Tunnicliffe commented on CASSANDRA-16404: - bq. Sam Tunnicliffe Your are familiar with that part of the code. Would you have some time for a review? Probably not for a few days, but I will try to take a look this week if that's any use. > 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: 40m > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375375#comment-17375375 ] Benjamin Lerer commented on CASSANDRA-16404: [~azotcsit] Once again sorry for the delay. I did not realized that the JMX interface for that part of the code tend to be nested within the implementation classes. So I would do the same despite what I said earlier. Otherwise the patch look good to me but we would need another +1 from a committer. [~samt] Your are familiar with that part of the code. Would you have some time for a review? > 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: 40m > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354276#comment-17354276 ] Benjamin Lerer commented on CASSANDRA-16404: All my apologizes for the delay [~azotcsit]. I have been stuck those last weeks on some 4.0 regressions. I will have a look at your patch in the coming days. > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352652#comment-17352652 ] Alexey Zotov commented on CASSANDRA-16404: -- [~blerer] [~sumanth.pasupuleti] Have you had a chance to check the changes? > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332735#comment-17332735 ] Alexey Zotov commented on CASSANDRA-16404: -- It turned out that AssertJ is preferable library for test assertions. I've converted all assertions in the PR from Hamcrest to AssertJ. > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326113#comment-17326113
]
Alexey Zotov commented on CASSANDRA-16404:
--
[~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>}}). 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320549#comment-17320549 ] Sumanth Pasupuleti commented on CASSANDRA-16404: Thanks [~blerer] for keeping me in loop for assignee change. I was waiting for the ticket to be triaged before implementing :), but thanks much to [~azotcsit] for taking this ticket forward with discussions and patch! [~azotcsit] I had a chance to review your patch and here are a few comments I have from the review. # In addition to roles having hierarchy that you already mention, even resources have hierarchy. It maybe worth considering clearing entries for all resources underneath a resource in context. # This [commit|https://github.com/apache/cassandra/pull/950/commits/e5660717deeb86872e4c868264f79f96c6b87d78] touches a lot more tests than just cache tests; I would recommend tackling that change as part of a separate ticket and change. # Code style - You may want to run the * intellij code styler; especially for same line vs next style braces styling. > 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: 20m > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315727#comment-17315727
]
Benjamin Lerer commented on CASSANDRA-16404:
Sorry for missing your questions.
{quote} 1. NetworkAuthCache has slightly different naming compared to other
auth caches: a) it has Auth suffix b) it has a "singular name". The naming for
nodetool commands matches class naming exactly. I feel it is the best way to
prevent further confusion in the code. Are we good with that? {quote}
The other option is to rename the cache but I do not know if there is some side
reasons for not doing it.
{quote} 2. I can see that Roles cache has some hierarchical logic for getting
roles and role resources by primary role. Currently I do invalidate only a
single role. Please, let me know if we need to have hierarchical invalidation
logic as well.{quote}
I do not recall exactly how the hierachy work. I would have to double check
that. You can let it like that for now.
{quote} 3. I see that similar nodetool commands do not have tests since they
are pretty simple. Do I need to try to introduce tests here? {quote}
As discussed above: Yes, it would be great.
{quote} 4. Currently three MBean interfaces (NetworkAuth, Permissions and
Roles) were introduced as separate files. Do I need to inline then as per
https://cwiki.apache.org/confluence/display/CASSANDRA2/CodeStyle ?{quote}
No, it is fine if the MBean interfaces are in separate files.
> 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: 20m
> 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315578#comment-17315578 ] Alexey Zotov commented on CASSANDRA-16404: -- [~blerer] Thanks for the quick response! It would be great if you could provide some input regarding other open questions in the PR description (unit tests was one of the questions). So I'll be able to address everything before your next review attempt. > 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: 20m > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315516#comment-17315516 ] Benjamin Lerer commented on CASSANDRA-16404: [~sumanth.pasupuleti] I reassigned the tiket to [~azotcsit] as he provided a patch for that ticket. I hope it is fine with you. [~azotcsit] Thanks a lot for the patch, I might not be able to review it properly before a couple of week. I had a quick look at your patch and one thing that would be gret is if you could had some unit tests to test the behavior of the changes. > 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: 20m > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314070#comment-17314070 ] Alexey Zotov commented on CASSANDRA-16404: -- [~blerer] Thanks for the details, they helped a lot! I raised a draft PR to validate the direction I follow, your feedback would be very helpful. Also, I posted a few questions related to the implementation. Once you confirm the direction, I'm going to make a round of local testing to ensure the functionality works as expected. > 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: Sumanth Pasupuleti >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[ https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310604#comment-17310604 ] Benjamin Lerer commented on CASSANDRA-16404: b.q. 1. Despite the use case sounds reasonable to me, does the product ever need this functionality? It is a tricky question. In an ideal world it should not. Any auth change request should automatically clear the corresponding caches. Now, in a real world even if we had that functionality, problems do happen and this functionality can be useful. b.q. 2. There are multiple caches (roles, permissions, network auth, credentials, JMX permissions), but I feel it is enough to invalidate permissions cache only to handle the use case. Could you please confirm? I would have to look as I forgot some of the logic but it would make sense to me to provide the functionality for all of them. b.q. 3. As far as I can see, the invalidation of permissions cache only does not affect (need for re-login or similar side effects) logged in users. So it is safe to invalidate the cache and does not bother all users of the system. Could you please confirm? Not sure I understand your question. b.q. 4 Even though permissions cache invalidation does not affect other users, we need to provide an optional user parameter, so the administrator can invalidate the cache for that particular user rather than for all users. Thoughts? We should always minimize which part of the cache we clean as repopulating the cache under high load can have a significant impact on a cluster. b.q. As far as I understand nodetool is executed on a single node, so the auth cache invalidation needs to be triggered on all nodes manually. It seems be slightly inconvenient for the administrator... Administrators have tools in place to deal with that problem. Nodetool is single node only. > 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 >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Fix For: 4.x > > > 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
[jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310460#comment-17310460
]
Alexey Zotov commented on CASSANDRA-16404:
--
[~brandon.williams], [~blerer]
Could you please assist with triaging this issue. I went through the code and
in general this ticket seems to be clear from technical perspective, but there
are a few points to clarify:
# Despite the use case sounds reasonable to me, does the product ever need
this functionality?
# There are multiple caches (roles, permissions, network auth, credentials,
JMX permissions), but I feel it is enough to invalidate permissions cache only
to handle the use case. Could you please confirm?
# As far as I can see, the invalidation of permissions cache only does not
affect (need for re-login or similar side effects) logged in users. So it is
safe to invalidate the cache and does not bother all users of the system. Could
you please confirm?
# Even though permissions cache invalidation does not affect other users, we
need to provide an optional {{user}} parameter, so the administrator can
invalidate the cache for that particular user rather than for all users.
Thoughts?
# As far as I understand {{nodetool}} is executed on a single node, so the
auth cache invalidation needs to be triggered on all nodes manually. It seems
be slightly inconvenient for the administrator... However, it provides better
control and it is how it is done for all (? not sure) other commands. Is there
a way (concept) to execute such a command on all nodes?
> 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
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.x
>
>
> 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
