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: | Postg롤 토토SQL : |
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
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 |