* Christian Ullrich wrote:
Magnus Hagander wrote:
On Mon, Jan 3, 2011 at 14:11, Christian Ullrich<ch...@chrullrich.net>
wrote:
This change has been tested and works correctly on FreeBSD 8.1, using
the Kerberos and GSSAPI libraries from Heimdal 1.4. The server is
running PostgreSQL 9.0.2 on Windows 2008.
Does this require some certain minimum version of the kerberos
libraries? Do you know if it works with just Heimdal or both Heimdal
and MIT?
it works with anything but the configuration I mentioned. I will do some
more testing this week, but I'm limited in the number of combinations I
can try; some randomly chosen Linux distributions with whatever Kerberos
they ship and the Heimdal from the FreeBSD 8 base system instead of the
port (if I can get PostgreSQL to build with that) against Windows 2003
and 2008 is probably going to be all I can offer. Expect a report early
next week.
This is what I tested this week. If there are any additional questions,
please let me know.
Clients tested
--------------
1 FreeBSD 8.1 (x86), Heimdal 1.4 (released Sep 2010)
2 Gentoo Linux (x86_64) 20110113, Heimdal 1.3.3 (released May 2010)
3 Gentoo Linux (x86_64) 20110113, MIT 1.9 (released Dec 2010)
4 Gentoo Linux (x86_64) 20110113, MIT 1.8.3 (released Aug 2010)
5 Ubuntu Linux (x86) 10.10, MIT 1.8.1 (released Apr 2010)
6 FreeBSD 7.0 (x86), Heimdal 0.7 (released Jun 2005)
7 Debian Linux (x86) 5.0.7, MIT 1.4 (released Jan 2005)
8 Debian Linux (x86) 5.0.7, Heimdal 0.7.2 (released Feb 2006)
Notes:
My approach in building PostgreSQL on the clients was to first get it to
build without the patch, then add the patch, do a minimal rebuild
("make") and test with databases configured for "md5" and "sspi"
authentication.
I also tried GNU shishi as a third Kerberos implementation, but could
not get it to even attempt to get a TGT.
2, 3, 4: These were the only Kerberos implementations available
in Portage, obviously very recent ones.
6: Heimdal 0.7 was the oldest release I could get to build
on this platform, and getting PostgreSQL to link against
it required some work.
7: MIT 1.4 is the first release that will build with gcc 4,
while the first release that PostgreSQL might possibly
compile with is 1.3. Everything before that does not
have a sufficient GSSAPI. For the GCC issue see GCC bug
#18799.
8: There was an interesting build issue in this configuration.
Linux glibc does not include strlcpy(), which is why both
libpgport and Heimdal's libroken have their own versions.
What happens is that PostgreSQL's configure, after
correctly determining that there is no declaration of
strlcpy() in the system headers, nevertheless detects
libroken's implementation and excludes it from libpgport.
Later, (at least) ecpg and initdb fail to link because it
is not there. I could not figure out how to force it to
be included in libpgport, so I had to use libroken instead.
Servers tested
--------------
A Windows Server 2008 (x86_64), PostgreSQL 9.0.2 (x86_64)
B Windows Server 2008R2 (x86_64), PostgreSQL 8.4.4 (x86)
C Windows Server 2003R2 (x86), PostgreSQL 9.0.2 (x86)
Notes:
A: This is the (production) installation I mentioned originally.
B, C: These are dedicatedldd testing installations.
Server configuration procedure
------------------------------
- Installed operating system
- Joined to domain
- Installed PostgreSQL
- Stopped service
- Created service account in domain, added SPNs using ADSIEdit
I used a "managed service account" for the 2008R2 server, which I then
installed on that server. Postgres on the 2003R2 server is using a
standard user account.
- Changed permissions on data directory
- Changed service logon
- Started service
Combinations tested successfully
--------------------------------
1 2 3 4 5 6 7 8
A X
B X X X X X X
C X X X
Combinations tested unsuccessfully
----------------------------------
1 2 3 4 5 6 7 8
A
B
C
Conclusion
----------
There is no detectable risk of SSPI-via-GSS authentication failure due
to interoperability problems between the client's GSSAPI and the
server's SSPI, no matter the versions involved. The only potential
exception is with a Windows 2000 server, which I did not have access to
and consequently did not test.
A number of pitfalls can hamper building PostgreSQL, especially with
older Kerberos implementations. These, however, will equally affect
builds that are intended to use only "traditional" GSSAPI authentication.
I am not sure what I may have done wrong in the case of client 8, which
was a Debian system installed using the minimal CD. Maybe I was missing
some package or other. Given that this was on Debian, it would surprise
me if it was a genuine bug in configure.
--
Christian
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
