Обсуждение: 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. 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? Thanks a lot. Mohan
> 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
>
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
>
> 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?). Ok. Someone more autoconfy than me will have to say something about that :-) > As far as the security issue with Kerberos, here is the > relevant thread > > http://mailman.mit.edu/pipermail/kerberos/2002-October/002043. > html > <http://mailman.mit.edu/pipermail/kerberos/2002-October/002043.html> > > I am sorry it was in Kerberos mailing list not Postgres. Ah, that explains me not seeing it. If you need protection against mitm and connection security, you should use TLS. We don't use Kerberos for encryption. //Magnus
Thanks.
As far as using TLS, it is good approach. Although, we don't need complete channel encryption for every transaction or query. I am looking at a more granular approach where
I can decide depending on the security of information exchange whether to encrypt the
channel or not (like using maybe GSSAPI). Is this something that will be considered down
the line?
Mohan
As far as using TLS, it is good approach. Although, we don't need complete channel encryption for every transaction or query. I am looking at a more granular approach where
I can decide depending on the security of information exchange whether to encrypt the
channel or not (like using maybe GSSAPI). Is this something that will be considered down
the line?
Mohan
On 2/6/06, Magnus Hagander < mha@sollentuna.net> wrote:
> 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?).
Ok. Someone more autoconfy than me will have to say something about that
:-)
> As far as the security issue with Kerberos, here is the
> relevant thread
>
> http://mailman.mit.edu/pipermail/kerberos/2002-October/002043.
> html
> < http://mailman.mit.edu/pipermail/kerberos/2002-October/002043.html>
>
> I am sorry it was in Kerberos mailing list not Postgres.
Ah, that explains me not seeing it.
If you need protection against mitm and connection security, you should
use TLS. We don't use Kerberos for encryption.
//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
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
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/
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