From: Heikki Linnakangas on 15 Apr 2010 02:35 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> So you'd prefer a message that is sometimes flat-out wrong over a >> message that is correct but less informative in the common case? I >> guess that could be right call, but it's not what I'd pick. > > Well, as I said, I think the only way to really improve this message > is to use a different wording for the REJECT case. I'm unconvinced > that the problem justifies that, but if you're sufficiently hot about > it, that is the direction to go in; not making the the message less > useful for the 99% case. How about a hint? FATAL: connection not authorized for host "[local]", user "foo", database "postgres" HINT: Make sure that you have a matching accept line in pg_hba.conf -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 15 Apr 2010 03:17 On Thu, 2010-04-15 at 00:24 -0400, Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > So you'd prefer a message that is sometimes flat-out wrong over a > > message that is correct but less informative in the common case? I > > guess that could be right call, but it's not what I'd pick. > > Well, as I said, I think the only way to really improve this message > is to use a different wording for the REJECT case. I'm unconvinced > that the problem justifies that, but if you're sufficiently hot about > it, that is the direction to go in; not making the the message less > useful for the 99% case. I think that would solve my original gripe, if I understood the idea. So instead of the typical "reject" instruction we also add a "rejectverbose" instruction that has a more verbose message. Docs would describe it as an additional instruction to assist with debugging a complex pg_hba.conf, with warning that if used it may assist the bad guys also. "pg_hba.conf rejects entry for host..." Patch for that would be simple and clear; I can add that if we agree. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 15 Apr 2010 09:08 Simon, * Simon Riggs (simon(a)2ndQuadrant.com) wrote: > So instead of the typical "reject" instruction we also add a > "rejectverbose" instruction that has a more verbose message. Docs would > describe it as an additional instruction to assist with debugging a > complex pg_hba.conf, with warning that if used it may assist the bad > guys also. Erm, so we'd add an option for this? That strikes me as pretty excessive. Not to be a pain, but I feel like the 'connection not authorized' argument plus a hint makes alot more sense. > "pg_hba.conf rejects entry for host..." "connection not authorized for host X user Y database Z" "HINT: Make sure your pg_hba.conf has the entries needed and the user has CONNECT privileges for the database" Or something along those lines (I added the other CONNECT issue because it's one I've run into in the past.. :). I do also wonder if we should consider having the error that's reported to the log differ from that which is sent to the user.. I realize that's a much bigger animal and might not help the novice, but it could help with debugging complex pg_hba's without exposing info to possible bad guys. Thanks, Stephen
From: Tom Lane on 15 Apr 2010 09:44 Stephen Frost <sfrost(a)snowman.net> writes: > * Simon Riggs (simon(a)2ndQuadrant.com) wrote: >> So instead of the typical "reject" instruction we also add a >> "rejectverbose" instruction that has a more verbose message. > Erm, so we'd add an option for this? That strikes me as pretty > excessive. I think Simon's point was that we'd need a different uaReject enum value internally in the code, so that the place where the message gets issued would be able to distinguish explicit REJECT entry from falling off the end of the file. Changing what the user is expected to put in the file would be silly. (I don't care for "rejectverbose" though. Maybe uaImplicitReject for the end-of-file case would be the most readable way.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 15 Apr 2010 11:28
On Wed, Apr 14, 2010 at 08:37:18PM -0400, Robert Haas wrote: > On Wed, Apr 14, 2010 at 8:31 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > > Tom Lane wrote: > >> Robert Haas <robertmhaas(a)gmail.com> writes: > >> > What's wrong with something like "connection not permitted" or > >> > "connection not authorized"? > >> > >> The case that we're trying to cater to with the existing wording > >> is novice DBAs, who are likely to stare at such a message and not > >> even realize that pg_hba.conf is what they need to change. > >> �Frankly, by the time anyone is using REJECT entries they are > >> probably advanced enough to not need much help from the error > >> message; but what you propose is an absolute lock to increase the > >> number of newbie questions on the lists by a large factor. > > > > Agreed. �I would rather have an inaccurate error message that > > mentions pg_hba.conf than an accurate one that doesn't. > > > > Error messages should always point at a solution, if possible. > > OK, how about "connection not authorized by pg_hba.conf"? +1. It's clear, and if an attacker can compromise pg_hba.conf, there's nothing PostgreSQL can do to help. I'd like to bring up the idea of an attacker who both has that access and doesn't know about pg_hba.conf just to dismiss it. Such a person might exist, but we don't need to bend things around a case so rare that it makes being struck by lightning look like a certainty. :) Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |