Re: "Optional ident" authentication

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "Optional ident" authentication
Date: 2006-11-27 02:05:03
Message-ID: 1101.1164593103@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Quite apart from security concerns, I find this design awkward.

That's really the basis of my objection to it: having an auth method
that changes the basic semantics of the surrounding logical structure
is, at best, awkward and confusing. When it's in a security-critical
context, those attributes get triple demerits because of the risk of
unforeseen consequences at the implementation level (eg, clients not
being prepared for two successive login challenges of different kinds),
not to mention the likelihood of an admin writing a pg_hba.conf file
that doesn't do what he expected because he didn't understand what would
happen.

The examples given at the top of the thread don't seem to me to justify
any new contortions anyway:

>> My personal itch is that I'd like to have an "ident sameuser"
>> authentication that falls back on, say, PAM authentication when system
>> user A wants to log into postgres under a different username B.

You can accomplish that with

local sameuser all ident sameuser
local all all pam

>> ... to grant a web application or daemon passwordless
>> login to its database while other users still need a password.

local webapp,daemon all ident sameuser
local all all pam

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-11-27 02:29:06 Re: [CORE] RC1 blocker issues
Previous Message Joshua D. Drake 2006-11-27 02:02:31 Re: [CORE] RC1 blocker issues