[ https://issues.apache.org/jira/browse/CASSANDRA-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544073#comment-13544073 ]
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: https://issues.apache.org/jira/browse/CASSANDRA-5112 > Project: Cassandra > Issue Type: Improvement > Components: API > Affects Versions: 1.2.0 > Reporter: Dirkjan Bussink > Priority: Minor > > I'm working on updating https://github.com/nedap/cassandra-auth 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 it. > 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 > MigrationManager.java:320, because the gossiper hasn't been started yet. > - 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: http://www.atlassian.com/software/jira