Thread: Kerberos principal to dbuser mapping
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
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
--- 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
> > > 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
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