Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal

On Wed, May 27, 2009 at 5:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> What this still leaves us with is whether that change is a bad idea or
> not.  I still think it's OK, but maybe Peter can point to something
> else.

I recompiled postgres with the auth.c patch.

This is only an issue if you are trying to connect as a principal
that's not the same as your current username. Where I work, we have
security and mode bits set up on Kerberos tickets and keytabs such
that you either have to be the user in question or root to get those
credentials. And we only have a couple of things that run as root with
others' principals.

There is a workaround to get the "expected behavior", just specify the
proper username in the connection parameters. This should be
explicitly said in the release notes.

/s/std/bin/runauth -a -l postgres /s/postgresql-8.4-beta/bin/psql -h
mitchell -p 49173 postgres
psql: FATAL: GSSAPI authentication failed for user "root"
FATAL: no pg_hba.conf entry for host "128.105.207.19", user "root",
database "postgres", SSL off

[root(at)mitchell ~]# /s/std/bin/runauth -a -l postgres
/s/postgresql-8.4-beta/bin/psql -h mitchell -p 49173 -U postgres
postgres
psql (8.4beta2)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

postgres=#

I should also point out that old clients still exhibit the old behavior.

[root(at)mitchell ~]# /s/std/bin/runauth -a -l postgres
/s/postgresql-8.3.6/bin/psql -h mitchell -p 49173 postgres
Welcome to psql 8.3.6 (server 8.4beta2), the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

WARNING: You are connected to a server with major version 8.4,
but your psql client is major version 8.3. Some backslash commands,
such as \d, might not work properly.

SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)

postgres=#

It was rather convenient to know that whatever Kerberos principal was
used was going to be the database user. The old behavior is more in
line with other Kerberos'd systems like AFS or NFSv4 that take their
authentication from the Kerberos principal (through an AFS token or
LDAP), sometimes regardless of the shell user. Of course, file systems
are different animals than DBMS's since they need to "always be on"
instead of requiring explicit connections every time you authenticate.
I can't think of any other major services that explicitly use
Kerberos, so I'm not sure how many other models exist.

From a practical standpoint, I can accept this change since there is a
simple workaround and since Kerberos is properly verifying the user.
Though it would be nice to make the assumption that the principal is
the user for Kerberos/GSSAPI connections, I don't think it's worth it
to differently handle that rare case where it would actually make a
difference.

Peter