From: Heikki Linnakangas on
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
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
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
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
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