Re: "Optional ident" authentication - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: "Optional ident" authentication
Date
Msg-id 456C5137.2030609@phlo.org
Whole thread Raw
In response to Re: "Optional ident" authentication  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "Optional ident" authentication
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> You can accomplish that with
>>>
>>> local    sameuser    all    ident sameuser
>>> local    all        all    pam
> 
>> You put "sameuser" in the database column instead of the "user" column -
>> was the intentional? I've just tried this with "sameuser" in the user 
>> column, and it didn't work for me.
> 
> You're right, I was confusing the database-column feature with what's
> involved here.  There isn't really any way for "sameuser" to work in the
> user column, since that would require a way to identify the user's
> non-database username, which is exactly the province of the auth method.
> So never mind :-(.
> 
> But I still question whether Jeroen's got any real use case that can't
> be handled the other way, viz

While I agree that the original proposal was a bit hackish, I'd love
to be able to specifiy "First try this auth method, and fall back to
another if the first didn't succeed".

I, for example, have a large ldap directory that contains one posixAccount
entry for each of my customers. Postgres on my database server authenticates
against that directory via pam, and my webservers are set up to run each
customers cgi-scripts under his own account. To make things easier
for customers, the webserver is running gidentd, and my database server uses
ident authentication for connections from the webserver. Thus you only need
to specify the database name and the hostname of my db server in cgi-scripts -
no need for passwords (or usernames).

Now, sometimes a customers cgi-scripts needs to be able to connect to another
customers database. Currently, I need to change pg_hba.conf to let him do that.
If I could chain authentication methods, I could just tell my customers they need
a password to connect to a foreign database, but don't one one to connect to their
own database.

I believe it would be sufficient to add an additional column to pg_hba.conf
called "On Failure". The value could either be "Continue" or "Abort", with
the default being "Abort" to match the current behaviour.

If there is a chance that a patch like that would be accepted I could try to
modify Jeroen's patch to support that - but I have very little free time at
the moment, so it might take me a while to get it done...

greetings, Florian Pflug



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Potential to_char localization bug
Next
From: "Florian G. Pflug"
Date:
Subject: Re: Shared pg_xlog directory/partition and warm standby