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
