Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Fri, May 13, 2011 at 00:21, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, May 10, 2011 at 05:39, Tom Lane t...@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/
commit 4c64761b53f1acec54af3c63b436d9f6defb845c
Author: Magnus Hagander mag...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Magnus Hagander mag...@hagander.net writes: On Fri, May 13, 2011 at 00:21, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, May 10, 2011 at 05:39, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Mon, May 30, 2011 at 20:39, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Fri, May 13, 2011 at 00:21, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, May 10, 2011 at 05:39, Tom Lane t...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Fri, May 13, 2011 at 00:21, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, May 10, 2011 at 05:39, Tom Lane t...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Magnus Hagander mag...@hagander.net writes: On Tue, May 10, 2011 at 05:39, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Tue, May 10, 2011 at 05:39, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Tom Lane wrote: Peter Eisentraut pete...@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 br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Bruce Momjian br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@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.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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Mon, Apr 25, 2011 at 18:59, Robert Haas robertmh...@gmail.com wrote: On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@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.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. 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Robert Haas robertmh...@gmail.com writes: On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Mon, Apr 25, 2011 at 19:11, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Magnus Hagander mag...@hagander.net writes: On Mon, Apr 25, 2011 at 18:59, Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Mon, Apr 25, 2011 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Mon, Apr 25, 2011 at 19:18, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Mon, Apr 25, 2011 at 18:59, Robert Haas robertmh...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Magnus Hagander mag...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On Mon, Apr 25, 2011 at 19:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Magnus Hagander mag...@hagander.net writes: On Mon, Apr 25, 2011 at 19:38, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
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
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off
On 04/25/2011 07:18 PM, Tom Lane wrote: Peter Eisentrautpete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
