[
https://issues.apache.org/jira/browse/CASSANDRA-18551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Nicolas updated CASSANDRA-18551:
---------------------------------------
Description:
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, with a new PVC / disk. 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.
was:
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.
> 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
> Priority: Normal
>
> 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, with a new PVC / disk. 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]
