On Fri, Oct 21, 2011 at 12:54 PM, Henrik Ingo <[email protected]> wrote: >> 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.
Yes. > 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. http://kb.askmonty.org/en/socket_peercred-authentication-plugin >> 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. If it's the default / recommended, it *will* be used in production. > 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. My point is that even when the channel is encrypted, you should not send plaintext passwords. > 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? Yes > drawbacks: > - need non-standard extra parameters to drizzle client? (I assume you > need some plugin, or could this be made to work by default? Nope, no client-side support necessary. > - 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". Something is still missing. The authentication question appears to be answered. What about the authorization question? -- Olaf _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
