The current implementation of the kerberos 5
authentification in backend/libpq/auth.c truncates the
principal after the first '/' or failing that, after
the first '@', assuming the result to be the database
username. This implicitly allows crossrealm
autentification which is not good in many instances.
Even more seriously, it discards parts following any
'/' which is definatelly very bad in many instances.

This is not satisfactory for some (I would think most)
applications. A solution to this would be mapping
kerberos principals to usernames in the database. (As
e.g ~username/.k5login determines which principals are
authorized to login as username.) Idealy this mapping
table should be a system table in the database (and
not a specialized file like the current implementation
of pg_ident.conf). Is this a stupid idea? Any
comments?

I do have a few my questions regarding an
implementation of this.

Is there any existing way of making queries from
postmaster (other than setting up a client connection
from it)?

Is there a reason pg_ident.conf and pg_hba.conf are
files rather than tables?

Is there any reason not doing authentification of both
the client and the server?

Grateful for answers and comments
Daniel


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Wed, 15 May 2002 13:43:32 +0100 (BST)
=?iso-8859-1?q?Daniel?= <dah00002000@yahoo.co.uk>
Kerberos principal to dbuser mapping
=?iso-8859-1?q?Daniel?= <dah00002000@yahoo.co.uk> writes:
> The current implementation of the kerberos 5
> authentification in backend/libpq/auth.c truncates the
> principal after the first '/' or failing that, after
> the first '@', assuming the result to be the database
> username. This implicitly allows crossrealm
> autentification which is not good in many instances.

I agree, that's probably not a good idea.

> This is not satisfactory for some (I would think most)
> applications. A solution to this would be mapping
> kerberos principals to usernames in the database. (As
> e.g ~username/.k5login determines which principals are
> authorized to login as username.) Idealy this mapping
> table should be a system table in the database (and
> not a specialized file like the current implementation
> of pg_ident.conf). Is this a stupid idea?

Afraid so.  The postmaster cannot use system tables because it's
not really connected to the database.

You could possibly add a column to pg_shadow that gets dumped into
the "flat password file" for use by the postmaster.

Offhand, though, that seems like overkill.  Why not just add a
postgresql.conf parameter for realm name, and if it's set, only accept
Kerberos principal names from that realm?  Or even simpler, a boolean
that says to accept only names from the same realm as our own ticket?
These would be much simpler to implement and probably solve 99.44% of
the problem.  In the boolean form, I'd even favor setting it to "on"
by default, so that the default configuration becomes more secure.
With anything else, security can only be improved if the admin takes
special action to insert the correct information.

> Is there any existing way of making queries from
> postmaster (other than setting up a client connection
> from it)?

There is no existing way, and none will be added in the future either.
There are good system-reliability reasons for keeping the postmaster
away from the database.

> Is there any reason not doing authentification of both
> the client and the server?

Say again?

			regards, tom lane

Wed, 15 May 2002 10:13:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Kerberos principal to dbuser mapping 
 --- Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 
> You could possibly add a column to pg_shadow that
> gets dumped into
> the "flat password file" for use by the postmaster.

Yes, I had the thought of creating a trigger on insert
into pg_shadow, which would issue a COPY TO statement
and a custom c-function to send the signals to
postmaster. But that is inelegant to say the least.
 
> Offhand, though, that seems like overkill.  Why not
> just add a
> postgresql.conf parameter for realm name, and if
> it's set, only accept
> Kerberos principal names from that realm?  Or even
> simpler, a boolean
> that says to accept only names from the same realm
> as our own ticket?
> These would be much simpler to implement and
> probably solve 99.44% of
> the problem.

It would only solve the crossrealm authentification
problem. I would call that the minor problem of the
two. The more important one is that the current code
throws away any components following a '/'. That means
that two distinct principals, say webserver/www1@b.com
and webserver/webmail@b.com is regarded as equivalent
for database authenification purposes. That is not
correct. Since the usernames in Postgres has
restrictions regarding valid characters, it is not
recomendable (though probably possible) to have
usernames matching the entire principal.

A table, matching principal against username, would
solve both problems. (While still allowing crossrealm
authentification on a per-user basis.)

This is actually what pg_an_to_ln should do, but the
kerberos implementation is not suitable in this
context regardless of if it "punts" (what is that?) or
not. This is due to postgresql maintaining its own
user database, separate from the local machines. One
cant expect that the kerberos implementation should be
able to perform this translation for postgres. The
database must do that itself and, preferably, in a
correct manner.

> With anything else, security can only be improved if
> the admin takes
> special action to insert the correct information.

I do not understand your last statement in this
context.

> > Is there any existing way of making queries from
> > postmaster (other than setting up a client
> connection
> > from it)?
> 
> There is no existing way, and none will be added in
> the future either.
> There are good system-reliability reasons for
> keeping the postmaster
> away from the database.

Ok, but it seems wasteful to build primitive database
functionality in parallell to the real database.

The way I see it there is one main problem. We have a
krb principal with a structure we need not assume we
know anything about. We should certainly not then
discard bits and pieces of it. In order to not loose
functionality we would like several principals to be
authorized to use a given username and several
usernames to be accessible by a given principal. The
way to solve this is to use a translation method from
principal to database users, i. e. a table.
As the number of users of the database grows, using a
preprocessed flat file to manage this becomes more and
more of a problem. At that point one usually begins to
look for the functionality of a database, and one is
certainly close at hand :).
 
> > Is there any reason not doing authentification of
> both
> > the client and the server?
> 
> Say again?

Sorry, I was jumping between subjects.
Why is not simply AP_OPTS_MUTUAL_REQUIRED specified in

the krb5_recvauth call in auth.c and in the
krb5_sendauth in fe-auth.c? This would not only ensure
the server that it is talking to the right client but
also ensure the client it is talking to the right
server.

Regards
Daniel



__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Wed, 15 May 2002 19:38:20 +0100 (BST)
=?iso-8859-1?q?Daniel?= <dah00002000@yahoo.co.uk>
Re: Kerberos principal to dbuser mapping 
> > > Is there any existing way of making queries from
> > > postmaster (other than setting up a client
> > > connection from it)?
> > 
> > There is no existing way, and none will be added in
> > the future either.
> > There are good system-reliability reasons for
> > keeping the postmaster
> > away from the database.
> 
> Ok, but it seems wasteful to build primitive database
> functionality in parallell to the real database.

This issue affects mutual SSL authentication and PKIX in 
addition to Kerberos.  See a followup post for details....
Bottom line: we should identify and document a canonical
solution.

P.S., in the case of PKIX, there's a well-defined interface
and there's no conceptual problem with maintaining the database
via the regular client interface.  Bootstrapping the system may
be another matter.

Bear

Thu, 16 May 2002 09:09:11 -0600 (MDT)
Bear Giles <bgiles@coyotesong.com>
Re: Kerberos principal to dbuser mapping
Daniel writes:

> way to solve this is to use a translation method from
> principal to database users, i. e. a table.
> As the number of users of the database grows, using a
> preprocessed flat file to manage this becomes more and
> more of a problem. At that point one usually begins to
> look for the functionality of a database, and one is
> certainly close at hand :).

The server cannot access the database before you're authenticated to do
so, plus if the authentication setup is contained in the database and you
mess it up, how do you get back in?  These are the two reasons why the
information is kept in flat files.  One might come up with ways to edit
these files from within the SQL environment, which indeed is a frequently
requested feature, but for solving the problem at hand, namely the
Kerberos principal to PostgreSQL user mapping, use a flat file.  You can
probably use most of the ident.conf code.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 16 May 2002 19:21:56 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Kerberos principal to dbuser mapping 