Re: Patch to add Heimdal kerberos support - Mailing list pgsql-patches

From Bill Studenmund
Subject Re: Patch to add Heimdal kerberos support
Date
Msg-id Pine.NEB.4.33.0111130826310.26615-100000@vespasia.home-net.internetconnect.net
Whole thread Raw
In response to Re: Patch to add Heimdal kerberos support  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch to add Heimdal kerberos support
List pgsql-patches
On Mon, 12 Nov 2001, Tom Lane wrote:

> I said:
> > Well, it's not clear to me.  Where did the ticket come from?  Perhaps
> > we've already determined that you are who you say you are just by being
> > able to acquire the ticket.
>
> After doing a little light reading (RFC 1510...) it seems that what the
> Kerberos auth exchange actually gives you is confidence that the other
> party is the Kerberos principal named in the ticket you got from him.
> We don't use the claimed Postgres username in the process of acquiring
> the ticket, so there's no automatic cross-check as I was hoping.  We
> must look at the principal name.

Exactly.

> The problem from our point of view is that a Kerberos principal name
> is a multi-part entity, and it's not entirely clear how to map that into
> a Postgres username.  I'm moderately unhappy with the solution used in
> the code now: take the first name component, ignore all else, including
> the realm.  This appears to mean that a server living in Kerberos realm
> k1 will happily accept people from different realms, eg joe@k2, without
> noticing that this is not the same person as joe@k1.  Bad dog.

Hmmm... That is bad. You do have to have cross-realm authentication set
up to need to worry, but yes, if you do, you have a problem.

For now the right thing probably is to pull out the realm and make sure it
is the same. Eventually it would be nice to do something like list
principals (name@realm) which can log in as postgres user foo. Like what
.klogin does for telnet.

But that is going a bit beyond making pg work with Heimdal, that's making
the krb5 code work better. :-)

Still checking on a good auto-detect.

> It also seems that our present code may be using some long-deprecated
> Kerberos APIs --- for example, the krb5_recvauth man pages I can find on
> the net describe several more parameters than our code is expecting to
> pass.  I suspect that that direct access to a field of the ticket is
> a hangover we should be able to get rid of.

For krb5_recvauth()? We are using the right function signature...

The general problem of directly accessing the ticket is one which porting
to Heimdal revealed. The MIT code was routinely accessing library-private
bits of info. There's an effort afoot to clean this up, but I don't think
it's far-enough along yet. Plus a number of OSs have shipped with the
non-unified version of Heimdal. :-|

Take care,

Bill


pgsql-patches by date:

Previous
From: Karel Zak
Date:
Subject: Re: stupid patch of pg_dumplo
Next
From: Tom Lane
Date:
Subject: Re: Enhanced index details using \d in psql