Обсуждение: Allow peer/ident to fall back to md5?
Hi all At pgconf-eu Álvaro and I were discussing the idea of allowing 'peer' and 'ident' authentication to fall back to md5 if the peer/ident check failed. This can be done backwards compatibly and without protocol changes. A client won't be able to tell that the pg_hba.conf line wasn't 'md5'. I think this would be a nice usability improvement, especially for new users who have no idea what a unix socket is and who're quite confused by this: $ sudo -u postgres psql -q postgres=# CREATE USER alpha WITH PASSWORD 'beta'; postgres=# $ psql -W -U alpha Password for user alpha: psql: FATAL: Peer authentication failed for user "alpha" ... or client-library equivalents using connstrings where the fact that any supplied password is ignored is less obvious. In terms of BC impact, it'd possibly cause clients to prompt for a password where they'd otherwise exit with an error - but that's kind of the idea. If anyone's concerned about that I think it'd be reasonable to add an option in pg_hba.conf to allow 'ident' and 'peer' to be qualified with a no_md5_fallback mode. On the server side, what we'd do is check ident/peer if set in pg_hba.conf . If it's rejected we'd store the details of why we rejected it, then send a password request packet for md5 authentication. If password auth succeeds we'd log in normally. If password auth fails, we'd emit an error along the lines of: FATAL: Peer authentication and md5 fallback both failed for user "alpha" DETAIL: Local user "me" doesn't match remote user "alpha" and md5 password was not sent or did not match. ... and we'd log the usual info about remote and local user not matching to the server error log too. Reasonable? I'm also inclined to add a DEBUG1 message along the lines of "peer authentication failed because of username mismatch but fallback md5 authentication succeeded" to the client on successful auth. They wouldn't normally see it, but it'd make it easier to trace what's going on if you ask for it. IMO doing this would give us the most important benefits of a proper authentication negotiation handshake with fallback - without requiring protocol changes. It doesn't let you do fancier stuff like "try GSSAPI, fall back to md5" ... but personally, if it deals with the issues around peer/ident, I'll be happy. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Craig Ringer <craig@2ndquadrant.com> writes:
> At pgconf-eu �lvaro and I were discussing the idea of allowing 'peer'
> and 'ident' authentication to fall back to md5 if the peer/ident check
> failed.
I think it would be acceptable to define *new* auth modes that work
that way. I'm violently against redefining the meaning of existing
pg_hba.conf entries like this: it's not terribly hard to imagine
cases where it'd be a security problem, and even if you claim it isn't,
people will get bent out of shape if they think you're poking holes
in their oh-so-carefully-chosen authentication arrangements.
> If anyone's concerned about that I think it'd be reasonable to
> add an option in pg_hba.conf to allow 'ident' and 'peer' to be qualified
> with a no_md5_fallback mode.
You've got that exactly backwards.
regards, tom lane
On 10/29/2014 10:45 AM, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> At pgconf-eu Álvaro and I were discussing the idea of allowing 'peer'
>> and 'ident' authentication to fall back to md5 if the peer/ident check
>> failed.
>
> I think it would be acceptable to define *new* auth modes that work
> that way. I'm violently against redefining the meaning of existing
> pg_hba.conf entries like this: it's not terribly hard to imagine
> cases where it'd be a security problem, and even if you claim it isn't,
> people will get bent out of shape if they think you're poking holes
> in their oh-so-carefully-chosen authentication arrangements.
Well, that's why I mentioned control over fallback via an option to
peer/ident below.
>> If anyone's concerned about that I think it'd be reasonable to
>> add an option in pg_hba.conf to allow 'ident' and 'peer' to be qualified
>> with a no_md5_fallback mode.
>
> You've got that exactly backwards.
There's no point adding a usability improvement that's off by default.
Distros can still enable it, though, and they're what I'm interested in.
Nobody uses PostgreSQL's initdb default for pg_hba.conf ('trust') anyway.
I don't care in the slightest how it's spelled; these:
peer peer with_md5_fallback peer md5_fallback=on peer_or_md5
... or whatever else. Personally I'm not concerned about allowing a user
who has login rights on the database to log in with a correct password
in a new major release where we can release-note the change, but if you
are, I don't much care if it's off by default in core. Distros can fix that.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Oct 29, 2014 at 10:52:38AM +0800, Craig Ringer wrote:
> On 10/29/2014 10:45 AM, Tom Lane wrote:
> > Craig Ringer <craig@2ndquadrant.com> writes:
> >> At pgconf-eu Álvaro and I were discussing the idea of allowing 'peer'
> >> and 'ident' authentication to fall back to md5 if the peer/ident check
> >> failed.
> >
> > I think it would be acceptable to define *new* auth modes that work
> > that way. I'm violently against redefining the meaning of existing
> > pg_hba.conf entries like this: it's not terribly hard to imagine
> > cases where it'd be a security problem, and even if you claim it isn't,
> > people will get bent out of shape if they think you're poking holes
> > in their oh-so-carefully-chosen authentication arrangements.
Switching from today's "peer" to the proposed method in a given installation
can indeed open a security hole. If you accept peer authentication only,
quality of account passwords is irrelevant. Using this mode requires setting
a strong password or no password at all.
> There's no point adding a usability improvement that's off by default.
>
> Distros can still enable it, though, and they're what I'm interested in.
> Nobody uses PostgreSQL's initdb default for pg_hba.conf ('trust') anyway.
Switching away from "trust" has been a safe call for distributions, because
every other method is strictly less permissive. "md5_or_peer" would be
strictly more permissive than either "md5" or "peer", so a distribution
switching to the new mode would be betting that the extra usability makes up
for folks overlooking the change and getting a security hole. (I think the
care needed to vet a switch from md5 to md5+peer is less than that needed to
vet a switch from peer to md5+peer.)
> I don't care in the slightest how it's spelled; these:
>
> peer
> peer with_md5_fallback
> peer md5_fallback=on
> peer_or_md5
Think about making this an option of the "peer" method that allows trying
subsequent pg_hba.conf lines when "peer" fails. Call it something like
"continue" or "sufficient". pg_hba.conf would have:
local all all peer continue
local all all md5
This lets you pair peer authentication with methods other than md5.
Thanks,
nm
On 2014-10-29 10:52:38 +0800, Craig Ringer wrote: > peer > peer with_md5_fallback > peer md5_fallback=on > peer_or_md5 If, we should make it generic. Like 'peer, md5'. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 2014-10-29 02:39:49 -0400, Noah Misch wrote: > local all all peer continue I like this one. But then I perhaps edited too many pam configuration files. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 10/29/2014 05:46 PM, Andres Freund wrote: > I like this one. But then I perhaps edited too many pam configuration > files. It seems good to me too. I haven't looked at how viable it is in implementation terms. I think we could only properly support 'continue' on peer/ident in the v3 protocol. With other protos we need to negotiate with the client before we determine that we can't authenticate them and we send them an auth failed message. I guess we could just send a different auth request to the client instead of an auth failed message, but it might confuse clients that aren't expecting it, and it'd make it harder to report the original auth failure if we carry on to try something else. The advantage of doing it for peer/ident is that there's no conversation with the client required, so the client never needs to know that we considered peer/ident before falling back to something else. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2014-10-29 02:39:49 -0400, Noah Misch wrote:
> > local all all peer continue
>
> I like this one. But then I perhaps edited too many pam configuration
> files.
I don't particularly like it, for much the same reason...
I'd be fine with "fallback-to-md5" or something though, which distros
could choose to set.
Thanks,
Stephen
On 10/29/2014 02:52 AM, Craig Ringer wrote: > On 10/29/2014 05:46 PM, Andres Freund wrote: >> I like this one. But then I perhaps edited too many pam configuration >> files. > > It seems good to me too. I haven't looked at how viable it is in > implementation terms. > > I think we could only properly support 'continue' on peer/ident in the > v3 protocol. With other protos we need to negotiate with the client > before we determine that we can't authenticate them and we send them an > auth failed message. > > I guess we could just send a different auth request to the client > instead of an auth failed message, but it might confuse clients that > aren't expecting it, and it'd make it harder to report the original auth > failure if we carry on to try something else. > > The advantage of doing it for peer/ident is that there's no conversation > with the client required, so the client never needs to know that we > considered peer/ident before falling back to something else. I don't see a problem with having a "continue" directive, and documenting that it only works with peer and ident. Maybe someday (protocol bump) we can have a way to make other methods continue, and then nobody will need to change their files to support the new way. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 10/29/14, 11:23 AM, Josh Berkus wrote: > I don't see a problem with having a "continue" directive, and > documenting that it only works with peer and ident. Maybe someday > (protocol bump) we can have a way to make other methods continue, and > then nobody will need to change their files to support the new way. Keep in mind that makes it far easier to accidentally screw up your hba.conf by putting a line in the wrong place. Anyonethat's dealt with firewall rules (or apparently PAM) would probably be OK, but a lot of our users would end up witha config that's not doing what they wanted. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com