Re: SSPI client authentication in non-Windows builds - Mailing list pgsql-hackers

* Christian Ullrich wrote:

> Magnus Hagander wrote:

>> On Mon, Jan 3, 2011 at 14:11, Christian Ullrich<chris@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
linkagainst         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
issuesee GCC bug         #18799.
 

8:       There was an interesting build issue in this configuration.         Linux glibc does not include strlcpy(),
whichis why both         libpgport and Heimdal's libroken have their own versions.         What happens is that
PostgreSQL'sconfigure, after         correctly determining that there is no declaration of         strlcpy() in the
systemheaders, nevertheless detects         libroken's implementation and excludes it from libpgport.         Later,
(atleast) 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
2003R2server 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