cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5112) Setting up authentication tables with custom authentication plugin
Date Fri, 04 Jan 2013 17:58:14 GMT


Aleksey Yeschenko commented on CASSANDRA-5112:

Yep. I mean RF=2/3 with CL.ONE. There is risk, though repair doesn't *have* to ignore system_auth,
this can be changed.

What else can we do?
1. when logging in, don't require the username to be in system_auth.users - rely on the response
of IAuthenticator.authenticate() and don't perform this additional check
2. modify AU.isSuperUser() to return false if it gets TOE or UAE

If we do 1 and 2 and a node with your user fails, then you won't be able to do all the things,
but at least you'd be able to login and do *most* of the things.

> Setting up authentication tables with custom authentication plugin
> ------------------------------------------------------------------
>                 Key: CASSANDRA-5112
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 1.2.0
>            Reporter: Dirkjan Bussink
>            Priority: Minor
> I'm working on updating with the new authentication
API's in Cassandra 1.2.0. I have stumbled on an issue and I'm not really sure how to handle
> For the authentication I want to setup additional column families for the passwords and
permissions. As recommended in the documentation of IAuthorizer, I'm trying to create these
tables during setup(): "Setup is called once upon system startup to initialize the IAuthorizer.
For example, use this method to create any required keyspaces/column families.".
> The problem is that doing this seems to be a lot harder than I would think, or I'm perhaps
missing something obvious. I've tried various attempts, but all have failed:
> - CQL and QueryProcessor.processInternal to setup additional column families. This fails,
since processInternal will throw a UnsupportedOperationException due to it being a SchemaAlteringStatement.
> - CQL and QueryProcessor.process. This works after the system has successfully started,
but due to the moment setup() is called in the Cassandra boot process, it will fail. It will
throw an AssertionError in, because the gossiper hasn't been started
> - Internal API's. Mimicking how other column families are set up, using CFMetadata and
Schema.load. This seems to get the system in some inconsistent state where some parts do see
the additional column family, but others don't.
> Does anyone have a recommendation for the path to follow here? What would be the recommended
approach for actually setting up those column families during starting for authentication?
> From working on this, I also have another question. I see the default system_auth keyspace
is created with a SimpleStrategy and a replication factor of 1. Is this a deliberate choice?
I can imagine that if a node in a cluster dies, losing the authentication information that
happens to be available on that code could be very problematic. If I'm missing any reasoning
here, please let me know, but it struck me as something that could cause potential problems.
I also don't see a way I could reconfigure this at the moment, and API's such as CREATE USER
do seem to depend on this keyspace.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message