we should ignore authentication if there are no users created

[dgolja]

Hello,

just a suggestion, but wouldn't make sense that even if the authentication is enabled, but there are no users created yet, the authentication get ignored or at least let us create the default admin ? For example mongodb has a similar approach, described here (http://docs.mongodb.org/manual/core/authentication/#localhost-exception). An design like that would make automated configuration with puppet and similar tools way easier.

If you guys agree I am happy to create a PR.

[pauldix]

That sounds more usable to me, we'd happily take a PR for it :)

[dgolja]

cool ... In that case then we have few options

• extend the current GRANT ALL PRIVILEGES syntax and add an option to setup the password at the same time. For example something like GRANT ALL PRIVILEGES TO jdoe WITH PASSWORD
• extend the localhost exception that it can run only CREATE USER foo WITH PASSWORD 'something' and GRANT ALL PRIVILEGES TO foo. This are two commands and it's a bit confusing.

If I could choose I would go with the first option

[pauldix]

You're thinking the GRANT ALL PRIVILEGES TO jdoe WITH PASSWORD would create the user? That is a little confusing to me. I'd prefer to keep it as two separate statements.

Your init script could still do it in a single query (GET request) to the server. You just have the create user statement then a ; then the grant privileges statement.

You can have multiple statements in a query.

[corylanou]

@pauldix we had it sort of this way once, and specifically removed it because it created significant issues lower in the code. I can't remember the exact specifics, and we might have evolved our code past those issues by now, but I do remember that it was a real problem having it allow a "one time free throw".

As for simply ignoring auth turned on if no users are created, this strikes me as a pretty serious security vulnerability. Imagine a user configuring their system, turning on auth, forgetting to create a user (or the script he used fails to create the user and he doesn't realize it). Then, he updates his client to use the users he THINKS were created. Everything works fine as it ignores auth, but the server is actually not secure at all.

[pauldix]

@corylanou I remember when that got removed and I was very much against it since I think having this in makes things much more usable.

Although I think the problem there was that we had a situation where the "first user" could be created (but from anywhere). In this case it has the limitation that it can only be done against from the localhost so maybe that'll make it easier?

I think what's being suggested here is that the config file has auth enabled. That means that all requests against the database will fail initially. Until the setup script (this person is probably using puppet, chef, or ansible) then creates the admin user from the localhost.

Then clients will be free to do things against the database with the user that exists. I didn't see this as suggesting that auth should be ignored if no users are created. The flag in the config is what should be followed.

The only exception is if you're making a request from localhost you can create users and give them privileges. At least that's my understanding of it.

[dgolja]

@pauldix correct, that's the idea.

If authentication is enable, but there are no admin users you will be able to create the admin user via localhost. Once the first admin user is created you will need to use proper authentication.

I will have a look at the code during the weekend and hopefully I will be able to easily add this functionality.

However there is a potential problem. With that design you will be able to create more than one user, until one of them is clusteradmin . That was the reason why I was hoping to have one line command to create a clusteradmin.

[corylanou]

How are we going to validate the request came from the localhost?

[dgolja]

didnt have a chance to have a look at the code yet, but can't we just check if the request destination is localhost (127.0.0.1) we know it was generated from localhost ?

[corylanou]

None of that information is reliable. It's easily spoofed if you wanted to launch an attack. Also, if the box was ever compromised, then checking this also wouldn't help.

To be clear, I agree that our current scenario is less than ideal. But due to being open source, it's not if we get hacked, it's when. I'm still searching for a way to do this that doesn't leave a back door open. I do want to find another way, but so far, none of these strike me as ideal. I know I'm probably the minority on this thinking.

[dgolja]

yeah definitely it's not ideal, but we need something like that if not automating installs become really painful.

On the other side this "initial" user creation will be available only for a short period of time. MongoDB is using a similar approach and for example ES doesn't have any kind of authentication :)

[corylanou]

@n1tr0g I mis-read the intention. I agree that if we are bound to the localhost interface that we can do this one time creation. It's probably as secure as we are going to get anything. If someone compromises your box, I'm willing to say we aren't responsible after that :-).

[beckettsean]

@gunnaraasen what's the status on this? Didn't we already implement this?

[gunnaraasen]

This is partially implemented.

We do not currently check if the request is from localhost when there are no users and auth is enabled. Should be easy to check, just need to add it.

[beckettsean]

@gunnaraasen, I talked with @pauldix today and he's on board with the runtime user creation workaround. E.g. with auth enabled you can only create a user as a cluster admin OR by passing a specific user creation flag to influxd.

[beckettsean]

@jwilder @rkuchan @gunnaraasen I think we already did this, didn't we?

[jsternberg]

I can see this code inside of 0.13 and it's probably been there for longer than that. I'm going to close this.