Re: Kerberos principal to dbuser mapping

--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)b(dot)com
and webserver/webmail(at)b(dot)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