On Fri, Oct 21, 2011 at 12:40 PM, Olaf van der Spek <[email protected]> wrote: > On Fri, Oct 21, 2011 at 11:28 AM, Henrik Ingo <[email protected]> > wrote: >>> For localhost, we should support peercred auth via unix domain >>> sockets. I was supposed to implement that during GSoC, but that was >>> the only part I didn't manage to do. >> >> But is this something that will just work by default? Do you have good links? > > It's Linux-only (AFAIK), but it's available by default. See > http://linux.die.net/man/7/socket > AFAIK it tells you the user ID of your peer.
Ah, so if you're logged in and connect to localhost, no password at all is needed. This is even better than auth_pam. This is how apps commonly authenticate you on Windows, for instance you can connect to SQL Cluster like this, and the new MySQL proprietary auth for windows does it too. I'd never heard a similar mechanism exist on unix/linux. >>> So where does that plaintext password come from? Typically it's stored >>> in a conf file (of the client app). >> >> I'm thinking more of the use case where you use the drizzle client app >> and type in the password. >> Either way, in all use cases I know of the password is input to the >> client in plain text format anyway. How to store that securely in an >> app is a different problem - all the ones I've seen just store it in >> plaintext in a file, including well known PHP apps like Drupal. > > True. That's bad, but it's not a system account password. So if it's > compromised, the damage is (probably) much less. Agree. So in any case this is not good for production usage, only for a DBA or developer logging in manually. >>> SSL isn't completely secure, especially due to the situation with certs. >> >> And you are suggesting instead? > > I'm no crypto expert. So I'd use an existing auth mechnism design. > Probably something based on challenge, response, hashing. > > Let's take a step back. What problem are we trying to solve? Yes. Now we are confusing things: SSL was suggested to encrypt the communication channel, not for authentication (even if it could do that too). Inside the secure channel, you can still use whatever authentication method you prefer. The original problem I suppose is to have a secure authentication plugin that is easier to use than auth_ldap. This is adequately solved by Daniel's auth_schema - bonus for being a familiar concept to anyone who has used MySQL. I then ventured into being more user friendly: A secure way of connecting to drizzled without having to create any users at all. Currently this user frienliness is provided in Drizzle by auth_all and in MySQL by defaulting to empty root password. This is not just a convenience thing for lazy hackers, for instance all tutorials ever written for MySQL assume you are using the default and will work when a newbie copy pastes the examples into his command line. auth_pam seems like a relatively good solution for allowing this: - no need to create users, just use your system username - no empty password, use your system password drawbacks were - need to use non-standard extra parameters to drizzle client (could be solved by having those in a configuration file) - sends password in cleartext over the wire (could be solved by SSL) - using system password also for Drizzle can also decrease security (as you now pointed out), so this would not be recommended for production servers, but neither is empty root password. It seems with peercred you'd have: - no password needed at all when connecting from localhost - reuses your system username? drawbacks: - need non-standard extra parameters to drizzle client? (I assume you need some plugin, or could this be made to work by default? - only works on localhost - but this is actually a feature if you compare with above :-) > For a simple developer setup, listening on localhost only and not > using passwords doesn't sound so bad to me. I suppose it's ok too, now that I think about it. There is a small benefit in not having empty password at all, but all above alternatives had their drawbacks too. Including peercred, if you end up needing some extra parameters when invoking "drizzle". henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
