Peter Eisentraut <pete...@gmx.net> writes:
> On mån, 2011-04-25 at 13:11 -0400, Tom Lane wrote:
>> Or we could go in the direction of making hostssl lines be a silent
>> no-op in both cases, but that doesn't seem like especially
>> user-friendly design to me. We don't treat any other cases in
>> pg_hba.conf comparably AFAIR.
> We ignore "local" even if the system doesn't have Unix-domain sockets.
> We ignore IPvN entries even if listen_addresses doesn't contain any IPvN
> addresses (this could be considered equivalent to ssl = on/off).
> In my experience, it is best to ignore these things. You don't lose
> anything -- if you don't have SSL configured, no one is going to connect
> with SSL -- and at best you're going to annoy admins who want to
> configure systems consistently.
Hmm, interesting point, but the problem is that issues like the current
one are likely to continue to rear their heads if we try to promise that
you can write pg_hba lines that aren't really supported on the current
installation. And this immediate problem (clientcert=1 causing an
unexpected failure) is far from the only thing that would have to be
fixed to handle that. For instance, we throw error if you say
authmethod = PAM without any PAM support ... should we try to change
that so that the error doesn't happen if it's in a line that "can't
possibly" match an incoming connection? I doubt it.
In the particular case at hand, if someone is trying to use the same
hostssl-containing pg_hba.conf across multiple systems, is it not
reasonable to suppose that he should have SSL turned on in
postgresql.conf on all those systems? If he doesn't, it's far more
likely to be a configuration mistake that he'd appreciate being pointed
out to him, instead of having to reverse-engineer why some of the
systems aren't working like others.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
