Unfriendly handling of pg_hba SSL options with SSL off
A recent complaint in pgsql-novice revealed that if you have say
hostssl all all 127.0.0.1/32 md5 clientcert=1
in pg_hba.conf, but you forget to enable SSL in postgresql.conf,
you get something like this:
LOG: client certificates can only be checked if a root certificate store is available
HINT: Make sure the root.crt file is present and readable.
CONTEXT: line 82 of configuration file "/home/tgl/version90/data/pg_hba.conf"
LOG: client certificates can only be checked if a root certificate store is available
HINT: Make sure the root.crt file is present and readable.
CONTEXT: line 84 of configuration file "/home/tgl/version90/data/pg_hba.conf"
FATAL: could not load pg_hba.conf
Needless to say, this is pretty unhelpful, especially if you actually do
have a root.crt file.
I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is "hostssl", check not only that SSL
support is compiled but that it's turned on. Is it really sensible to
allow hostssl lines in pg_hba.conf when SSL is turned off? At best
they are no-ops, and at worst they're going to result in weird failures
like this one.
regards, tom lane
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
A recent complaint in pgsql-novice revealed that if you have say
hostssl all all 127.0.0.1/32 md5 clientcert=1
in pg_hba.conf, but you forget to enable SSL in postgresql.conf,
you get something like this:LOG: client certificates can only be checked if a root certificate store is available
HINT: Make sure the root.crt file is present and readable.
CONTEXT: line 82 of configuration file "/home/tgl/version90/data/pg_hba.conf"
LOG: client certificates can only be checked if a root certificate store is available
HINT: Make sure the root.crt file is present and readable.
CONTEXT: line 84 of configuration file "/home/tgl/version90/data/pg_hba.conf"
FATAL: could not load pg_hba.confNeedless to say, this is pretty unhelpful, especially if you actually do
have a root.crt file.I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is "hostssl", check not only that SSL
support is compiled but that it's turned on. Is it really sensible to
allow hostssl lines in pg_hba.conf when SSL is turned off? At best
they are no-ops, and at worst they're going to result in weird failures
like this one.
It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an error?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Apr 25, 2011 at 18:59, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
A recent complaint in pgsql-novice revealed that if you have say
hostssl all all 127.0.0.1/32 md5 clientcert=1
in pg_hba.conf, but you forget to enable SSL in postgresql.conf,
you get something like this:LOG: client certificates can only be checked if a root certificate store is available
HINT: Make sure the root.crt file is present and readable.
CONTEXT: line 82 of configuration file "/home/tgl/version90/data/pg_hba.conf"
LOG: client certificates can only be checked if a root certificate store is available
HINT: Make sure the root.crt file is present and readable.
CONTEXT: line 84 of configuration file "/home/tgl/version90/data/pg_hba.conf"
FATAL: could not load pg_hba.confNeedless to say, this is pretty unhelpful, especially if you actually do
have a root.crt file.I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is "hostssl", check not only that SSL
support is compiled but that it's turned on. Is it really sensible to
allow hostssl lines in pg_hba.conf when SSL is turned off? At best
they are no-ops, and at worst they're going to result in weird failures
like this one.It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an error?
It would absolutely have to be treat it as an error. another option
would be to throw a more specific warning at that place, and keep the
rest of the code the same.
We can't *ignore* hostssl rows in ssl=off mode, that would be an easy
way for an admin to set up a system they thought was secure but
isn't...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Robert Haas <robertmhaas@gmail.com> writes:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is "hostssl", check not only that SSL
support is compiled but that it's turned on.
It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an error?
Sorry, I wasn't clear. I meant to throw an error. We already do throw
an error if you put hostssl in pg_hba.conf when SSL support wasn't
compiled at all. Why shouldn't we throw an error if it's compiled but
not turned on?
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.
regards, tom lane
On Mon, Apr 25, 2011 at 19:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is "hostssl", check not only that SSL
support is compiled but that it's turned on.It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an error?Sorry, I wasn't clear. I meant to throw an error. We already do throw
an error if you put hostssl in pg_hba.conf when SSL support wasn't
compiled at all. Why shouldn't we throw an error if it's compiled but
not turned on?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 need to be very careful about ignoring *anything* in pg_hba.conf,
since it's security configuration. Doing it silently is even worse..
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Apr 25, 2011 at 18:59, Robert Haas <robertmhaas@gmail.com> wrote:
It's not clear to me what behavior you are proposing. �Would we
disregard the hostssl line or treat it as an error?
It would absolutely have to be treat it as an error. another option
would be to throw a more specific warning at that place, and keep the
rest of the code the same.
We can't *ignore* hostssl rows in ssl=off mode, that would be an easy
way for an admin to set up a system they thought was secure but
isn't...
No, I don't see that it's a security hole. What would happen if the
line is ignored is you couldn't make connections with it. I think you
are positing that it'd be a potential security problem if a connection
attempt fell through that line and then succeeded with some later line
that had less-desirable properties --- but if your pg_hba.conf contents
are like that, you already have issues, because a non-SSL-enabled client
is going to reach that later line anyway.
Nonetheless, it's extremely confusing to the admin to ignore such a
line, and that's not a good thing in any security-sensitive context.
regards, tom lane
On Mon, Apr 25, 2011 at 1:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is "hostssl", check not only that SSL
support is compiled but that it's turned on.It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an error?Sorry, I wasn't clear. I meant to throw an error. We already do throw
an error if you put hostssl in pg_hba.conf when SSL support wasn't
compiled at all. Why shouldn't we throw an error if it's compiled but
not turned on?
OK, I think you're right.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Apr 25, 2011 at 19:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Apr 25, 2011 at 18:59, Robert Haas <robertmhaas@gmail.com> wrote:
It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an error?It would absolutely have to be treat it as an error. another option
would be to throw a more specific warning at that place, and keep the
rest of the code the same.We can't *ignore* hostssl rows in ssl=off mode, that would be an easy
way for an admin to set up a system they thought was secure but
isn't...No, I don't see that it's a security hole. What would happen if the
line is ignored is you couldn't make connections with it. I think you
are positing that it'd be a potential security problem if a connection
attempt fell through that line and then succeeded with some later line
that had less-desirable properties --- but if your pg_hba.conf contents
are like that, you already have issues, because a non-SSL-enabled client
is going to reach that later line anyway.
Good point.
Nonetheless, it's extremely confusing to the admin to ignore such a
line, and that's not a good thing in any security-sensitive context.
Yeah, better make any misconfiguration very clear - let's throw an error.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
Yeah, better make any misconfiguration very clear - let's throw an error.
OK, so we need something like (untested)
if (token[4] == 's') /* "hostssl" */
{
#ifdef USE_SSL
+ if (!EnableSSL)
+ {
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+ errmsg("hostssl requires SSL to be turned on"),
+ errhint("Set ssl = on in postgresql.conf."),
+ errcontext("line %d of configuration file \"%s\"",
+ line_num, HbaFileName)));
+ return false;
+ }
parsedline->conntype = ctHostSSL;
#else
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
errmsg("hostssl not supported on this platform"),
errhint("Compile with --with-openssl to use SSL connections."),
errcontext("line %d of configuration file \"%s\"",
line_num, HbaFileName)));
return false;
#endif
}While I'm looking at this, I notice that here (and in some other places
in pg_hba.conf) we say "not supported on this platform" which seems
rather bogus to me. It implies that it's not possible to have SSL
support on the user's machine, which is most likely not the case.
I'd be happier with "not supported by this build of PostgreSQL" or some
such wording. Thoughts?
regards, tom lane
On Mon, Apr 25, 2011 at 19:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Yeah, better make any misconfiguration very clear - let's throw an error.
OK, so we need something like (untested)
if (token[4] == 's') /* "hostssl" */ { #ifdef USE_SSL + if (!EnableSSL) + { + ereport(LOG, + (errcode(ERRCODE_CONFIG_FILE_ERROR), + errmsg("hostssl requires SSL to be turned on"), + errhint("Set ssl = on in postgresql.conf."), + errcontext("line %d of configuration file \"%s\"", + line_num, HbaFileName))); + return false; + } parsedline->conntype = ctHostSSL; #else ereport(LOG, (errcode(ERRCODE_CONFIG_FILE_ERROR), errmsg("hostssl not supported on this platform"), errhint("Compile with --with-openssl to use SSL connections."), errcontext("line %d of configuration file \"%s\"", line_num, HbaFileName))); return false; #endif }
Looks good to me.
While I'm looking at this, I notice that here (and in some other places
in pg_hba.conf) we say "not supported on this platform" which seems
rather bogus to me. It implies that it's not possible to have SSL
support on the user's machine, which is most likely not the case.
I'd be happier with "not supported by this build of PostgreSQL" or some
such wording. Thoughts?
There seems to be a number of cases in libpq, and also in pg_locale.c
that says just hat. But in guc.c, we say "SSL is not supported by
this build". If we change it, we should change it to the same
(including whether "of PostgreSQL" is included).
Refering to the build seems more logical, yes.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Apr 25, 2011 at 19:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
While I'm looking at this, I notice that here (and in some other places
in pg_hba.conf) we say "not supported on this platform" which seems
rather bogus to me. �It implies that it's not possible to have SSL
support on the user's machine, which is most likely not the case.
I'd be happier with "not supported by this build of PostgreSQL" or some
such wording. �Thoughts?
There seems to be a number of cases in libpq, and also in pg_locale.c
that says just hat. But in guc.c, we say "SSL is not supported by
this build". If we change it, we should change it to the same
(including whether "of PostgreSQL" is included).
Refering to the build seems more logical, yes.
Since there's already precedent for saying "this build" full stop, let's
just go with that. I was already thinking that including the product
name in translatable strings would cause issues for repackagers.
Barring objections, I'll backpatch the added error check, but change the
wording of the existing messages only in HEAD.
regards, tom lane
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.
On mån, 2011-04-25 at 19:12 +0200, Magnus Hagander wrote:
We need to be very careful about ignoring *anything* in pg_hba.conf,
since it's security configuration. Doing it silently is even worse.
You're not really "ignoring" anything. It's just not going to be a
match.
Peter Eisentraut <peter_e@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
On mån, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
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.
I think, people use and configure PostgreSQL in all kinds of ways, so we
shouldn't assume what they might be thinking. Especially if an
artificial boundary has the single purpose of being "helpful". If
people want their configuration checked for "sanity" (by someone's
definition), there might be logging or debugging options in order for
that.
Peter Eisentraut <peter_e@gmx.net> writes:
On mån, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
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.
I think, people use and configure PostgreSQL in all kinds of ways, so we
shouldn't assume what they might be thinking. Especially if an
artificial boundary has the single purpose of being "helpful".
Well, it's not just to be "helpful", it's to close off code paths that
are never going to be sufficiently well-tested to not have bizarre
failure modes. That helps both developers (who don't have to worry
about testing/fixing such code paths) and users (who won't have to deal
with the bizarre failure modes).
But in any case, I think that the presence of a hostssl line in
pg_hba.conf is pretty strong evidence that the admin intends to use SSL,
so we should tell him about it if he's forgotten the other piece of
setup he needs.
If people want their configuration checked for "sanity" (by someone's
definition), there might be logging or debugging options in order for
that.
If anyone else agrees with your viewpoint, maybe we could compromise on
emitting a LOG message indicating that the hostssl line will be ignored
due to SSL being turned off. But I think your approach penalizes people
who make simple mistakes in order to lend marginal support to an
entirely-hypothetical advanced use case.
regards, tom lane
On mån, 2011-04-25 at 15:26 -0400, Tom Lane wrote:
Well, it's not just to be "helpful", it's to close off code paths that
are never going to be sufficiently well-tested to not have bizarre
failure modes. That helps both developers (who don't have to worry
about testing/fixing such code paths) and users (who won't have to
deal with the bizarre failure modes).
That's of course another good reason.
Peter Eisentraut <peter_e@gmx.net> writes:
On mån, 2011-04-25 at 15:26 -0400, Tom Lane wrote:
Well, it's not just to be "helpful", it's to close off code paths that
are never going to be sufficiently well-tested to not have bizarre
failure modes. That helps both developers (who don't have to worry
about testing/fixing such code paths) and users (who won't have to
deal with the bizarre failure modes).
That's of course another good reason.
Hm, does that mean we have consensus on treating it as an error?
If not, would some other people care to cast votes?
regards, tom lane
On 04/25/2011 07:18 PM, Tom Lane wrote:
Peter Eisentraut<peter_e@gmx.net> writes:
On mån, 2011-04-25 at 15:26 -0400, Tom Lane wrote:
Well, it's not just to be "helpful", it's to close off code paths that
are never going to be sufficiently well-tested to not have bizarre
failure modes. That helps both developers (who don't have to worry
about testing/fixing such code paths) and users (who won't have to
deal with the bizarre failure modes).That's of course another good reason.
Hm, does that mean we have consensus on treating it as an error?
If not, would some other people care to cast votes?
+1 for error.
cheers
andrew
On mån, 2011-04-25 at 19:18 -0400, Tom Lane wrote:
Hm, does that mean we have consensus on treating it as an error?
Regarding the patch you committed: I would avoid hardcoding
"postgresql.conf" in error or hint messages, since we don't know whether
that's the actual name of the file. No other message has that file name
hardcoded.
Peter Eisentraut <peter_e@gmx.net> writes:
On mån, 2011-04-25 at 19:18 -0400, Tom Lane wrote:
Hm, does that mean we have consensus on treating it as an error?
Regarding the patch you committed: I would avoid hardcoding
"postgresql.conf" in error or hint messages, since we don't know whether
that's the actual name of the file. No other message has that file name
hardcoded.
Fair enough --- do you have a proposal for alternate wording?
regards, tom lane
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On m��n, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
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.I think, people use and configure PostgreSQL in all kinds of ways, so we
shouldn't assume what they might be thinking. Especially if an
artificial boundary has the single purpose of being "helpful".Well, it's not just to be "helpful", it's to close off code paths that
are never going to be sufficiently well-tested to not have bizarre
failure modes. That helps both developers (who don't have to worry
about testing/fixing such code paths) and users (who won't have to deal
with the bizarre failure modes).But in any case, I think that the presence of a hostssl line in
pg_hba.conf is pretty strong evidence that the admin intends to use SSL,
so we should tell him about it if he's forgotten the other piece of
setup he needs.
Late reply, but we are basically ignoring 'local' lines if the build
doesn't support unix domain sockets (windows), but throwing an error for
hostssl usage if ssl is not compiled in. Is the only logic here that
'local' is part of the default pg_hba.conf and hostssl is not? Is that
good logic?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
Late reply, but we are basically ignoring 'local' lines if the build
doesn't support unix domain sockets (windows), but throwing an error for
hostssl usage if ssl is not compiled in. Is the only logic here that
'local' is part of the default pg_hba.conf and hostssl is not? Is that
good logic?
I wouldn't have a problem with making the Windows port throw an error
for "local" lines. We'd have to fix initdb to remove that line from the
sample file (if it doesn't already), but that's surely not hard.
regards, tom lane
On Tue, May 10, 2011 at 05:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
Late reply, but we are basically ignoring 'local' lines if the build
doesn't support unix domain sockets (windows), but throwing an error for
hostssl usage if ssl is not compiled in. Is the only logic here that
'local' is part of the default pg_hba.conf and hostssl is not? Is that
good logic?I wouldn't have a problem with making the Windows port throw an error
for "local" lines. We'd have to fix initdb to remove that line from the
sample file (if it doesn't already), but that's surely not hard.
It does already (that's what the @remove-line-for-nolocal@ markup in
the sample file is for).
So +1 for making it throw an error.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Tue, May 10, 2011 at 05:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wouldn't have a problem with making the Windows port throw an error
for "local" lines. �We'd have to fix initdb to remove that line from the
sample file (if it doesn't already), but that's surely not hard.
It does already (that's what the @remove-line-for-nolocal@ markup in
the sample file is for).
So +1 for making it throw an error.
Although this should be a simple change, I don't want to do it because
I'm not in a position to test it. Do you want to take care of it?
regards, tom lane
On Fri, May 13, 2011 at 00:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, May 10, 2011 at 05:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wouldn't have a problem with making the Windows port throw an error
for "local" lines. We'd have to fix initdb to remove that line from the
sample file (if it doesn't already), but that's surely not hard.It does already (that's what the @remove-line-for-nolocal@ markup in
the sample file is for).So +1 for making it throw an error.
Although this should be a simple change, I don't want to do it because
I'm not in a position to test it. Do you want to take care of it?
I can take a look at it, but it probably won't happen until during or
after pgcon.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Fri, May 13, 2011 at 00:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, May 10, 2011 at 05:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wouldn't have a problem with making the Windows port throw an error
for "local" lines. We'd have to fix initdb to remove that line from the
sample file (if it doesn't already), but that's surely not hard.It does already (that's what the @remove-line-for-nolocal@ markup in
the sample file is for).So +1 for making it throw an error.
Although this should be a simple change, I don't want to do it because
I'm not in a position to test it. Do you want to take care of it?
Here's a patch that I think does what we want. It works fine on
Windows - I just want to make sure this is what you meant as well?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
hba_nolocal.patchtext/x-patch; charset=US-ASCII; name=hba_nolocal.patchDownload
commit 4c64761b53f1acec54af3c63b436d9f6defb845c
Author: Magnus Hagander <magnus@hagander.net>
Date: Mon May 30 20:11:13 2011 +0200
Refuse "local" lines in pg_hba.conf on platforms that don't support it
This makes the behavior compatible with that of hostssl, which
also throws an error when there is no SSL support included.
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index c17863f..f3a3b6e 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -824,7 +824,16 @@ parse_hba_line(List *line, int line_num, HbaLine *parsedline)
token = lfirst(line_item);
if (strcmp(token, "local") == 0)
{
+#ifdef HAVE_UNIX_SOCKETS
parsedline->conntype = ctLocal;
+#else
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+ errmsg("local connections are not supported by this build"),
+ errcontext("line %d of configuration file \"%s\"",
+ line_num, HbaFileName)));
+ return false;
+#endif
}
else if (strcmp(token, "host") == 0
|| strcmp(token, "hostssl") == 0
Magnus Hagander <magnus@hagander.net> writes:
On Fri, May 13, 2011 at 00:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, May 10, 2011 at 05:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wouldn't have a problem with making the Windows port throw an error
for "local" lines. We'd have to fix initdb to remove that line from the
sample file (if it doesn't already), but that's surely not hard.
Here's a patch that I think does what we want. It works fine on
Windows - I just want to make sure this is what you meant as well?
Looks sane to me.
regards, tom lane
On Mon, May 30, 2011 at 20:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Fri, May 13, 2011 at 00:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, May 10, 2011 at 05:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wouldn't have a problem with making the Windows port throw an error
for "local" lines. We'd have to fix initdb to remove that line from the
sample file (if it doesn't already), but that's surely not hard.Here's a patch that I think does what we want. It works fine on
Windows - I just want to make sure this is what you meant as well?Looks sane to me.
Ok, thanks. Applied.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/