When cyrus-sasl-2.1.25-r3 configuration script attempts to verify the existence of the gsskrb5_register_acceptor_identity function, the test fails although it exists in the mit-krb5-1.9.4-r1 library. As a consequence when programs such as cyrus-imapd-2.4.16 attempts to use the sasl_keytab configuration option, it will silently fail (instead pointing to the default /etc/krb5.keytab) which when used returns a generic SASL "Permission denied" error. Reproducible: Always The workaround for Gentoo is to patch the init.d script just before the start-stop-daemon with a "[ -n "$KRB5_KTNAME" ] && export KRB5_KTNAME", and in the conf.d for cyrus append "KRB5_KTNAME=/etc/cyrus.keytab". This same fix is necessary for the openldap-2.4.30 (and older) to support GSSAPI (as there seems to be no other method to assign service specific keytabs within the configuration options). If the maintainers will please forward this upstream, and for the interim the workaround will hopefully help others users in the same predicament.
> When cyrus-sasl-2.1.25-r3 configuration script attempts to verify the existence of the gsskrb5_register_acceptor_identity function, the test fails although it exists in the mit-krb5-1.9.4-r1 library. The valid response to this is "attach build log / config.log".
Please post your `emerge --info' output in a comment. *** This bug has been marked as a duplicate of bug 445568 ***
Created attachment 331408 [details] Emerge --info per request Not really that useful (as this will occur on any MIT Kerberos library system using the gssapi_krb5.h line 164 redefinition)
Created attachment 331410 [details] Config.log per request Around about line 2926 you should find the "undefined reference", and thus the failure.
I do not believe this is a duplicate of 445568 as that is a postfix authentication issue, and this is a SASL implementation of GSSAPI configuration issue. In postfix-2.9.4 there is an option "import_environment = KRB5_KTNAME=/etc/postfix/smtp.keytab" which does the equivalent without having to patch the init files.
@previous bug summary: close, but no. configure:14869: x86_64-pc-linux-gnu-gcc -o conftest -Wall -W -O2 -pipe -fno-strict-aliasing -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -DLDAP_DEPRECATED -I/usr/include/db4.8 -DOBSOLETE_CRAM_ATTR=1 -Wl,-O1 -Wl,--as-needed conftest.c -lgssapi -lgssapi -lkrb5 -lasn1 -lroken -lcrypt -lcrypto -lcom_err >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgssapi /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgssapi /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lasn1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lroken collect2: ld returned 1 exit status Where does mit-krb5 put those libs ?
Created attachment 331416 [details] mit-mrb5-1.9.4 equery At least this is the location for this installation. Odd as it succeeds later (see config.log line 3281)
OK, I've quoted the wrong configure test. The correct one does succeed, but gsskrb5_register_acceptor_identity is *not* a symbol provided by libgssapi_krb5 - that check fails with a clean error. configure:15396: x86_64-pc-linux-gnu-gcc -o conftest -Wall -W -O2 -pipe -fno-strict-aliasing -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -DLDAP_DEPRECATED -I/usr/include/db4.8 -DOBSOLETE_CRAM_ATTR=1 -Wl,-O1 -Wl,--as-needed conftest.c -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support >&5 /var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r3/temp/ccFcUwd5.o: In function `main': conftest.c:(.text+0x7): undefined reference to `gsskrb5_register_acceptor_identity' collect2: ld returned 1 exit status So, it seems your initial claim is wrong in some way.
And yet (per comment 3) it exists redefined as krb5_gss_register_acceptor_identity which is declared two lines later. My claim is that this configuration mistake leads to the cyrus-sasl plugin (see gssapi.c lines 1297-1322) to not support the option for non-default keytabs. Why this auto-generated code from configure (and working backwards aclocal.m4 line 10539) leads to and undefined reference, I'm sure upstream will be grateful for the solution (or perhaps at least the existence of an issue missing includes and all that).
@comment 9: AC_CHECK_LIB check *can't* detect symbols defined that way - it only checks the lib. How recent is that redefinition ? It wouldn't be the first time a kerberos implementation making a change, that breaks old checks - heimdal has done so to in the past.
...and I've actually meant AC_CHECK_FUNCS (see cmulocal/sasl2.m4).
heimdal has gsskrb5_registor_acceptor_identity but mit has krb5_gss_registor_acceptor_identity (but has a macro that uses this export). So, heimdal should work with service keytabs at the moment but mit won't. Fixing cmulocal/sasl2.m4 seems to be a better solution than defining environment variables or changing gssapi.c
(In reply to comment #12) > heimdal has gsskrb5_registor_acceptor_identity but mit has > krb5_gss_registor_acceptor_identity (but has a macro that uses this export). > So, heimdal should work with service keytabs at the moment but mit won't. > > Fixing cmulocal/sasl2.m4 seems to be a better solution than defining > environment variables or changing gssapi.c Well, "fixing" this might be quite annoying, due to the way the checks were used in the sources. It seems that something like this (instead of the existing line): AC_CHECK_FUNCS(gsskrb5_register_acceptor_identity, ,AC_CHECK_FUNCS(krb5_gss_register_acceptor_identity, AC_DEFINE(HAVE_GSSKRB5_REGISTER_ACCEPTOR_IDENTITY, [1]))) should work.
On unrelated note: did anyone notice how much of a mess cyrus-sasl 2.1.25 *tarball* is ? Seems to be uncompressed, with temporary/backup files lying around...
+*cyrus-sasl-2.1.25-r4 (05 Dec 2012) + + 05 Dec 2012; Eray Aslan <eras@gentoo.org> +cyrus-sasl-2.1.25-r4.ebuild, + +files/cyrus-sasl-2.1.25-service_keytabs.patch: + Service keytabs should work with mit-krb5 now - bug #445932 + Not really tested though. Please let me know if you are still having problems. Thanks for your report. (In reply to comment #14) > On unrelated note: did anyone notice how much of a mess cyrus-sasl 2.1.25 > *tarball* is ? The whole package is a mess.
Confirmed, this has fixed the issue. Thank you.
