Обсуждение: Re: [ADMIN] Postgres 8.1.x and MIT Kerberos 5

> Greetings,
>  I was trying to build source build postgres 8.1.x with MIT
> Kerberos 5 1.4.x implementation.
> The whole thing bombs out. After some digging, I had to hack
> the autoconf script (configure.in) to properly account for
> the way the libraries are built for 1.4.x. I don't know
> whether an earlier post had the same issue. I think it boils
> down to adding the 'libkrb5support' when all the krb5 libs
> are checked in the configure script.

(This is better asked in -hackers, I htink, copying there)

What platform is this? I use it with krb5 1.4.3 on Linux (slackware)
without any modifications at all. Perhaps platform specific behaviour?

The postmaster is linked to libkrb5support, but I only have "-lkrb5" in
my LIBS as generated by configure. However, if I do "ldd" on libkrb5.so
I see that one pulls in libkrb5support.


> On another note, is the kerberos authentication secure, I had
> searched some old threads, where it was indicated the
> principal is not checked by the db as a valid user. Is this
> still the case?

The principal name is definitly checked by the db as a valid user, and
AFAIK it always has been (do you have a reference to where it says it
doesn't?)

The *REALM* is not checked, however. This can cause problems if you have
a multi-realm system (where the realms already trust each other, because
the KDC has to give out the service ticket) where you have the same
username existing in multiple realms representing different users.

If you're in a single realm, it's definitly secure.

//Magnus

* Magnus Hagander (mha@sollentuna.net) wrote:
> The *REALM* is not checked, however. This can cause problems if you have
> a multi-realm system (where the realms already trust each other, because
> the KDC has to give out the service ticket) where you have the same
> username existing in multiple realms representing different users.

This brings up the issue again that it'd be nice to be able to have what
amounts to a '.k5login' in PostgreSQL somehow.  Ideally, this would be
something an idividual user could set up but at good first step would be
to have something along the lines of pg_ident.conf for Kerberos
connections where the admin could implement a mapping.

We should probably also have a configurable option to check the realm or
to not check the realm.  I'd like to look into doing this for 8.2 but,
as usual, I'm not sure I'll have time.  Anyone else looking into this?

    Thanks,

        Stephen

Hello Magnus,

Regarding the configure issue:
 The platform is Tru64 Unix 5.1b, the problem I had was we have
compiled our Kerberos build statically and is installed in a
directory other than the standard location. The trick adding to LIBS
did not work as it (krb5support) library needs to come after the
other libs (is there a way to control that?).


As far as the security issue with Kerberos, here is the relevant thread

http://mailman.mit.edu/pipermail/kerberos/2002-October/002043.html

I am sorry it was in Kerberos mailing list not Postgres.


On 2/5/06, Magnus Hagander <mha@sollentuna.net > wrote:
> > Greetings,
> >  I was trying to build source build postgres 8.1.x with MIT
> > Kerberos 5 1.4.x implementation.
> > The whole thing bombs out. After some digging, I had to hack
> > the autoconf script (configure.in) to properly account for
> > the way the libraries are built for 1.4.x. I don't know
> > whether an earlier post had the same issue. I think it boils
> > down to adding the 'libkrb5support' when all the krb5 libs
> > are checked in the configure script.
>
> (This is better asked in -hackers, I htink, copying there)
>
> What platform is this? I use it with krb5 1.4.3 on Linux (slackware)
> without any modifications at all. Perhaps platform specific behaviour?
>
> The postmaster is linked to libkrb5support, but I only have "-lkrb5" in
> my LIBS as generated by configure. However, if I do "ldd" on libkrb5.so
> I see that one pulls in libkrb5support.
>
>
> > On another note, is the kerberos authentication secure, I had
> > searched some old threads, where it was indicated the
> > principal is not checked by the db as a valid user. Is this
> > still the case?
>
> The principal name is definitly checked by the db as a valid user, and
> AFAIK it always has been (do you have a reference to where it says it
> doesn't?)
>
> The *REALM* is not checked, however. This can cause problems if you have
> a multi-realm system (where the realms already trust each other, because
> the KDC has to give out the service ticket) where you have the same
> username existing in multiple realms representing different users.
>
> If you're in a single realm, it's definitly secure.
>
> //Magnus
>

Mohan K wrote:
> Regarding the configure issue:
>  The platform is Tru64 Unix 5.1b, the problem I had was we have
> compiled our Kerberos build statically and is installed in a
> directory other than the standard location. The trick adding to LIBS
> did not work as it (krb5support) library needs to come after the
> other libs (is there a way to control that?).

I think what this comes down to is that we don't support static builds
very well at all.  So you will have to resort to editing
Makefile.global yourself after configuring.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter,
It is chicken and egg problem, I still need to enable kerberos in the configure script to make sure proper pieces are picked up. But of course
the configure script fails :).
If I provide the relevant patches to configure.in script is that acceptable?
thanks

Mohan K wrote:
> Peter,
> It is chicken and egg problem, I still need to enable kerberos in the
> configure script to make sure proper pieces are picked up. But of course
> the configure script fails :).
> If I provide the relevant patches to configure.in script is that acceptable?
> thanks

Probably if it isn't too ugly.

---------------------------------------------------------------------------


>
>
> On 2/6/06, Peter Eisentraut <peter_e@gmx.net> wrote:
> >
> > Mohan K wrote:
> > > Regarding the configure issue:
> > >  The platform is Tru64 Unix 5.1b, the problem I had was we have
> > > compiled our Kerberos build statically and is installed in a
> > > directory other than the standard location. The trick adding to LIBS
> > > did not work as it (krb5support) library needs to come after the
> > > other libs (is there a way to control that?).
> >
> > I think what this comes down to is that we don't support static builds
> > very well at all.  So you will have to resort to editing
> > Makefile.global yourself after configuring.
> >
> > --
> > Peter Eisentraut
> > http://developer.postgresql.org/~petere/
> >

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073