kern/147454: [libgssapi] libgssapi (heimdal) broken in head/, stable/8/, and releng/8.0/

[Reko Turja]

The following reply was made to PR kern/147454; it has been noted by GNATS.

From: "Reko Turja" <reko.turja at liukuma.net>
To: "bug-followup at FreeBSD.org"@liukuma.net
Cc: <ben at b1c1l1.com>
Subject: Re: kern/147454: [libgssapi] libgssapi (heimdal) broken in head/, stable/8/, and releng/8.0/
Date: Mon, 19 Jul 2010 01:25:23 +0300

 I've been testing different GSSAPI solutions this weekend based on=20
 broken kerberos thread in stable@ this weekend and had following=20
 experience:
 
 8-RELEASE GSSAPI segfaults on i386 and in amd64 doesn't recognise the=20
 mech used, but instead outputs to log:
 
  perl: GSSAPI Error:  Miscellaneous failure (see text) (unknown=20
 mech-code 2 for mech unknown)
 
 
 When linking cyrus-sasl2 against gssapi library from either the 1.0.1
 official port or the inofficial 1.2.1 patchset cyradm works as
 expected and it logs a message from gssapi/kerberos telling that no
 KDC's are available - which is to be expected on a system that isn't
 using gssapi/kerberos in authenticating.
 
 So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday
 the 5th is clearly some kind of regression as system gsslib doesn't
 seem to recognize the mech used or segfaults.
 
 After applying the patch from Benjamin, system csupped
 yesterday built okay and after rebuilding cyrus-sasl, saslauthd and
 cyrus I get the following failures in log:
 
 Jul 18 16:37:35 moria perl: GSSAPI Error:  Miscellaneous failure (see
 text)^B (open(/tmp/krb5cc_0): No such file or directory)
 
 -This is expected behaviour as Kerberos was not running at the moment,
 but with Benjamin's patch Kerberos/GSSAPI spat out a meaningful error
 message
 
 After dusting off my old Kerberos setup, doing basic kinit and running
 cyradm localhost I got:
 
 Jul 18 16:39:00 moria perl: GSSAPI Error:  Miscellaneous failure (see
 text) (Server (imap/localhost at XXX.DOMAIN.COM) unknown)
 
 -Again expected as there is no imap trust relationship defined.
 
 So at least after cursory testing it looks like that with Benjamin's
 patch there is a working GSSAPI/Kerberos backend available, instead of
 something that chokes on passed parameters that are ok for every other
 tested gssapi implementation.
 
 Of course, more thorough testing in proper kerberised/LDAP environment
 needs to be done, which is something I haven't got time at the moment.
 =20