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

On Mon, November 27, 2006 09:05, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Quite apart from security concerns, I find this design awkward.

It is.  I've considered adding a field, but that was a radical change to
the configuration file format and to the parsing code, which may also be
re-used for other purposes.


> 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),

Oh, I agree.  That's why I chose the solution that guaranteed at most one
interactive authentication method per login attempt.  Prompting the user
for, say, an LDAP password and then for a postgres password as an
alternative is confusing and unpleasant.

So I reasoned like this: when you stack authentication rules, only the
last one should ever be interactive.  Only one authentication method is
provably noninteractive: ident.  (Actually, ident already prompts for a
password if it fails--the password just doesn't go anywhere and that is
the part you can change with optident).

There is one other authentication method that *can* be noninteractive:
PAM.  Whether it is interactive depends on its own configuration.  PAM is
nicely flexible, but there is one thing it can't do.  It can't skip the
interaction when the client is already running under the right user
identity.  It can't do that because PAM is running in the client's process
context, which may be compromised.  There's just no reliable way for PAM
or any other client-side authentication library to know that it's really
running under the user id it thinks it is.

But ident, on the server side, does have reliable information in the form
of the client socket.  That makes "ident" a perfect complement to PAM or
other (interactive) authentication methods.

What I documented in my patch is "only noninteractive authentication
methods may fall through."  How that translates into a configuration file
format is a separate issue, but I figured it was better to introduce a new
authentication method than to change the configuration file format and
introduce an option to all authentication methods that really only makes
sense with one of them.


>>> 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

Yes, but I wouldn't call it more elegant or harder to misconfigure.  The
behaviour I'm looking for (and I think it's a fairly basic and useful
thing) is a combination of (1) coupling system user names to database user
names and (2) forgoing interaction when it's not needed.  What you suggest
here draws the database name into the equation, which to me is
counterintuitive and makes the solution less generic.

I'll agree that your example is harder to configure _unsafely_.  But when
people cannot get exactly the authentication scheme they want, they'll
usually end up with a more permissive one.  In that sense I don't see your
trick as inherently safer than optident.


>>> ... 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

Wait...  Tom, are you switching the database and user fields around? 
AFAICS this allows _all_ users passwordless access to databases called
"webapp" or "daemon."  Probably not what you want, but you might not
notice because your application kept running and people rarely complain
that they're not being prompted for a password.

If you're just doing this to prove your point about the risks of
misconfiguration, here's how you could do a similar thing with optident,
for all databases and users:

local    all    all        optident sameuser
local    all    all        pam

I think that's less error-prone, not more so.

Also, what if you want to grant specific system users passwordless login
under specific role names?  AFAICS you'd end up writing the username in
both the usermap *and* the user field of pg_hba.conf.  Let's say you have
a usermap that looked like this:

custommap  jack  webapp
custommap  jill  daemon

Now you can grant that access like this:

local    all    webapp,daemon  ident custommap
local    all    all            pam

With optident, you don't need the double listing of usernames:

local    all    webapp,daemon  ident custommap
local    all    all            pam

If you want to combine custommap with sameuser and still allow PAM login
for all other local connections:

local    all    all            optident custommap
local    all    all            optident sameuser
local    all    all            pam

You've shown that you can simulate this with the existing HBA, but at what
cost?  You're restricted to the case where database names match user
names.  You must remember to duplicate the usernames in your usermaps
exactly to the corresponding places in pg_hba.conf.  You still can't grant
system user jack passwordless login as "postgres" on two or more databases
while requiring passwords from everyone else who wants to do that.  And
you've shown us a dangerous mistake in just 4 lines using the existing
system.

All of this is easy with optident, AFAICS.  So what if my patch changes
the way HBA works?  The existing HBA may be good and simple, but it's not
perfect.  The patch gives you more flexibility in improving it: you can
add a "required but not sufficient" ident in the future, if you want, or
do other checks based on dynamic criteria.  You can have fallbacks from
mechanisms that aren't always available.  You get all of this without any
changes or incompatibilities to existing configuration files.  Any risk
happens when people choose to use it, and if they do, that probably means
that it's useful.


Jeroen