Pierre-Nicolas created CASSANDRA-18551:
------------------------------------------
Summary: New node has inconsistent permissions notwithstanding a
satisfying RF
Key: CASSANDRA-18551
URL: https://issues.apache.org/jira/browse/CASSANDRA-18551
Project: Cassandra
Issue Type: Bug
Components: Consistency/Bootstrap and Decommission,
Consistency/Repair, Feature/Authorization
Reporter: Pierre-Nicolas
h2. To reproduce
h3. Initial Setup
# Setup a 3-rack and 6-node cluster on Kubernetes, with disk persistency. Use
2 nodes per rack.
# Set the Replication Factor of the system_auth keyspace to 3.
# Set the authorizer to `org.apache.cassandra.auth.CassandraAuthorizer`.
# Create a `mytest` keyspace with RF=3, and a `myuser` user with read/write
permissions on the `mytest` keyspace.
# Connect to the DB using the `myuser` login/password. Auth works normally.
*Perturbation*
# Remove the PVC associated to one node (let's call it a-0, for "rack a, node
0").
# Delete the pod of node a-0.
# Let the pod restart, as part of the StatefulSet. A new node is created in
Cassandra, so that zone A is internally considered to have 3 nodes by
Cassandra, 2 of which are really running.
# When the pod is ready, connect to it using the `myuser` login/password.
# Run a `CREATE TABLE` in the `mytest` keyspace.
{*}--> ISSUE{*}: the statement fails with Unauthorized, it should not.
h2. Investigation and resolution
# Connect to the (new) a-0 pod using the `cassandra` superuser, with cqlsh.
# Execute `LIST ALL PERMISSIONS;`. You can see the `mytest` user has no
permissions on the `mytest` keyspace.
# Execute `SELECT ALL FROM system_auth.role_permissions;`. The table
auto-repairs and now you see the `mytest`-related permissions.
# Connect to the node using the `myuser` login/password. It now works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
