Re: 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
The *REALM* is not checked, however. This can cause problems if you
have a multi-realm system (where the realms already trusteach 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?
They're both on my personal TODO (not .k5login, but a
pg_ident-kind-of-mapping), but with the same disclaimer as you - I don't
know if I'll have enough time.
//Magnus
Import Notes
Resolved by subject fallback
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.
Show quoted text
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 threadhttp://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
Import Notes
Resolved by subject fallback
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
Show quoted text
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 threadhttp://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
Show quoted text
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