Bug 147454 - [libgssapi] libgssapi (heimdal) broken in head/, stable/8/, and releng/8.0/
Summary: [libgssapi] libgssapi (heimdal) broken in head/, stable/8/, and releng/8.0/
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-04 00:30 UTC by ben
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ben 2010-06-04 00:30:03 UTC
The heimdal-1.1 merge in head/ broke libgssapi.

For example, the entire lib/gssapi/mech directory is missing, which
defines many libgssapi functions:

blee@eclipse ~/src/heimdal-1.1/lib/gssapi/mech $ ls
context.c                         gss_krb5.c
context.h                         gss_mech_switch.c
cred.h                            gss_names.c
gss_accept_sec_context.c          gss_oid_equal.c
gss_acquire_cred.c                gss_oid_to_str.c
gss_add_cred.c                    gss_process_context_token.c
gss_add_oid_set_member.c          gss_pseudo_random.c
gss_buffer_set.c                  gss_release_buffer.c
gss_canonicalize_name.c           gss_release_cred.c
gss_compare_name.c                gss_release_name.c
gss_context_time.c                gss_release_oid.c
gss_create_empty_oid_set.c        gss_release_oid_set.c
gss_decapsulate_token.c           gss_seal.c
gss_delete_sec_context.c          gss_set_cred_option.c
gss_display_name.c                gss_set_sec_context_option.c
gss_display_status.c              gss_sign.c
gss_duplicate_name.c              gss_test_oid_set_member.c
gss_duplicate_oid.c               gss_unseal.c
gss_encapsulate_token.c           gss_unwrap.c
gss_export_name.c                 gss_utils.c
gss_export_sec_context.c          gss_verify.c
gss_get_mic.c                     gss_verify_mic.c
gss_import_name.c                 gss_wrap.c
gss_import_sec_context.c          gss_wrap_size_limit.c
gss_indicate_mechs.c              gssapi.asn1
gss_init_sec_context.c            mech.5
gss_inquire_context.c             mech.cat5
gss_inquire_cred.c                mech_locl.h
gss_inquire_cred_by_mech.c        mech_switch.h
gss_inquire_cred_by_oid.c         mechqueue.h
gss_inquire_mechs_for_name.c      name.h
gss_inquire_names_for_mech.c      utils.h
gss_inquire_sec_context_by_oid.c

Other parts of heimdal may be broken as well.

One related PR is ports/137729, which shows that the www/mod_auth_kerb2
port is broken due to the libgssapi breakage in base.

Fix: 

Clean up the merge with upstream's heimdal-1.1.
How-To-Repeat: Use libgssapi in FreeBSD 8.0+.
Comment 1 Stefan Walter freebsd_committer freebsd_triage 2010-06-25 11:06:47 UTC
Hi,

for the record, ports/145769 seems to describe a problem with fetchmail
resulting from this.

Regards,
Stefan
Comment 2 ben 2010-06-25 22:05:57 UTC
The following patch unbreaks libgssapi and upgrades it to be consistent
with the previous heimdal-1.1 merge:

http://www.b1c1l1.com/media/patches/libgssapi-9.0-CURRENT.diff.bz2
http://www.b1c1l1.com/media/patches/libgssapi-8.1-STABLE.diff.bz2

Currently, libgssapi is out of date because it was not upgraded when the
rest of heimdal was upgraded to heimdal-1.1.  Also, 3 new libraries
(libgssapi_krb5, libgssapi_ntlm, libgssapi_spnego) were unnecessarily
introduced -- MIT Kerberos separates these libraries, but Heimdal does
not.  This broke some libgssapi-dependent applications (e.g.
www/mod_auth_kerb2, PR #147282).

SHLIB_MAJOR is bumped from 10 to 11, so libgssapi-dependent applications
must be rebuilt after applying this patch.

I renamed some of upstream's files due to filename collisions.  If
buildworld can create corresponding subdirectories in obj/ to match
src/, then the renames are not necessary.

This patch went without comment on current@ and stable@.  Feedback is
appreciated.


-- 
Benjamin Lee
http://www.b1c1l1.com/
Comment 3 reko.turja 2010-07-18 23:25:23 UTC
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@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
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:12 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped