[HACKERS] Kerberos principal to dbuser mapping

[Tom Lane]

=?iso-8859-1?q?Daniel?= <dah00...@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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Bear Giles]

> > > 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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[Peter Eisentraut]

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 pet...@gmx.net

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)