--- Tom Lane <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] and [EMAIL PROTECTED] 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
