Skip site navigation (1) Skip section navigation (2)

Re: Reporting hba lines

From: Cédric Villemain <cedric(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: Reporting hba lines
Date: 2012-06-27 13:38:10
Message-ID: 201206271538.17450.cedric@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Le mercredi 27 juin 2012 14:54:15, Magnus Hagander a écrit :
> When debugging strange and complex pg_hba lines, it can often be quite
> useful to know which line is matching a particular connection that
> failed for some reason. Because more often than not, it's actually not
> using the line in pg_hba.conf that's expected.
> 
> The easiest way to do this is to emit an errdetail for the login
> failure, per this patch.
> 
> Question is - is that leaking information to the client that we
> shouldn't be leaking?

I fear it is exactly the problem. Too bad because the feature is interesting.

> And if it is, what would be the preferred way to deal with it? We
> could put that as a detail to basically every single error message
> coming out of the auth system, but that seems like a bad idea. Or we
> could make a separate ereport(LOG) before send it to the client,
> perhaps?

The problem is also that 1/ you're not sure how you did connect exactly  2/ 
you're not connecting like you wanted to do. (my case with ipv4 vs ipv6 just 
below). Providing more information on what we receive from client and tell it 
to the client  sounds good, no ?

> Thoughts?

I just consume some moment before fixing an ipv6 vs ipv4 login failure. The 
matched line from pg_hba .conf would have been very useful.

Maybe it is enough to report what happens on the connection: from which host, 
TCP/socket (and which  one, given that we should have multiple option here 
soon), dbname, user, .... inspecting pg_hba.conf will remain difficult if map is 
used or some other  +group option.

-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-27 13:40:01
Subject: Re: Posix Shared Mem patch
Previous:From: Kohei KaiGaiDate: 2012-06-27 13:07:55
Subject: Re: [v9.3] Row-Level Security

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group