Date: Wed, 28 Feb 2018 23:18:48 +1000 From: Da Rock <freebsd-apache@herveybayaustralia.com.au> To: freebsd-apache@freebsd.org Subject: Re: mod_auth_kerb2 causes apache to fail to start Message-ID: <9b6c9970-6c44-921d-7ff9-45712b86119c@herveybayaustralia.com.au> In-Reply-To: <fc451cdb-8e8d-12f0-e54f-c91d229fe62a@herveybayaustralia.com.au> References: <3fd7ffd1-c098-f8a2-47fb-9e26128fc68c@herveybayaustralia.com.au> <13686e25-b647-75a3-2f98-fda363b10b8e@herveybayaustralia.com.au> <2a435e14-d91c-8e80-79d1-e29df9a9ea93@herveybayaustralia.com.au> <fc451cdb-8e8d-12f0-e54f-c91d229fe62a@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/02/18 15:59, Da Rock wrote: > On 27/02/18 15:22, Da Rock wrote: >> On 27/02/18 13:16, Da Rock wrote: >>> On 27/02/18 12:43, Da Rock wrote: >>>> In theory I could submit this as a bug, but given the bug reports >>>> already and that have been closed without specific resolution I >>>> think that might not be a good idea. >>>> >>>> AFAICT most kerberos stuff has been geared toward using heimdal, >>>> and little testing has been done for mit krb5. What I have is an >>>> error: >>>> >>>> httpd: Syntax error on line 169 of >>>> /usr/local/etc/apache24/httpd.conf: Cannot load >>>> libexec/apache24/mod_auth_kerb.so into server: >>>> /usr/local/libexec/apache24/mod_auth_kerb.so: Undefined symbol >>>> "krb5_rc_dfl_init" >>>> >>>> This is a new install (entire base as well) with 11.1-Release and >>>> using krb5 from ports. >>>> >>>> ldd reveals: >>>> >>>> ldd /usr/local/libexec/apache24/mod_auth_kerb.so >>>> /usr/local/libexec/apache24/mod_auth_kerb.so: >>>> libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 >>>> (0x801208000) >>>> libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x801427000) >>>> libk5crypto.so.3.1 => /usr/local/lib/libk5crypto.so.3.1 >>>> (0x8016a5000) >>>> libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8018d9000) >>>> libc.so.7 => /lib/libc.so.7 (0x800824000) >>>> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801adb000) >>>> libcrypto.so.8 => /lib/libcrypto.so.8 (0x801e00000) >>>> libroken.so.11 => /usr/lib/libroken.so.11 (0x802269000) >>>> libasn1.so.11 => /usr/lib/libasn1.so.11 (0x80247c000) >>>> libcrypt.so.5 => /lib/libcrypt.so.5 (0x80271e000) >>>> libhx509.so.11 => /usr/lib/libhx509.so.11 (0x80293d000) >>>> libwind.so.11 => /usr/lib/libwind.so.11 (0x802b8a000) >>>> libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x802db2000) >>>> libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 >>>> (0x802fb6000) >>>> libkrb5support.so.0.1 => /usr/local/lib/libkrb5support.so.0.1 >>>> (0x8031b8000) >>>> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8033c6000) >>>> libthr.so.3 => /lib/libthr.so.3 (0x8035d1000) >>>> >>>> And here we can see that the module is looking in the wrong place >>>> for the gssapi and krb5 libs - /usr/lib rather than /usr/local/lib. >>> Output from make debug-krb: >>> >>> cc -O2 -pipe -fstack-protector -fno-strict-aliasing -o >>> /tmp/debug-krb.x -I"/usr/local/include" -lkrb5 -lgssapi_krb5 >>> -L"/usr/local/lib" -Wl,-rpath,/usr/local/lib /tmp/debug-krb.c && >>> ldd /tmp/debug-krb.x; /bin/rm -f /tmp/debug-krb.x >>> /tmp/debug-krb.x: >>> libkrb5.so.3.3 => /usr/local/lib/libkrb5.so.3.3 (0x800822000) >>> libgssapi_krb5.so.2.2 => /usr/local/lib/libgssapi_krb5.so.2.2 >>> (0x800b08000) >>> libc.so.7 => /lib/libc.so.7 (0x800d50000) >>> libk5crypto.so.3.1 => /usr/local/lib/libk5crypto.so.3.1 >>> (0x801108000) >>> libcom_err.so.3.0 => /usr/local/lib/libcom_err.so.3.0 (0x80133c000) >>> libkrb5support.so.0.1 => /usr/local/lib/libkrb5support.so.0.1 >>> (0x80153f000) >>> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x80174d000) >>> PREFIX: /usr/local >>> GSSAPIBASEDIR: /usr/local >>> GSSAPIINCDIR: /usr/local/include >>> GSSAPILIBDIR: /usr/local/lib >>> GSSAPILIBS: -lkrb5 -lgssapi_krb5 >>> GSSAPICPPFLAGS: -I/usr/local/include >>> GSSAPILDFLAGS: -L/usr/local/lib >>> GSSAPI_CONFIGURE_ARGS: CFLAGS=-I/usr/local/include -O2 -pipe >>> -fstack-protector -fno-strict-aliasing LDFLAGS=-L/usr/local/lib >>> -Wl,-rpath,/usr/local/lib:/usr/lib -fstack-protector LIBS=-lkrb5 >>> -lgssapi_krb5 KRB5CONFIG=/usr/local/bin/krb5-config >>> KRB5CONFIG: /usr/local/bin/krb5-config >>> CFLAGS: -O2 -pipe -fstack-protector -fno-strict-aliasing >>> LDFLAGS: -Wl,-rpath,/usr/local/lib:/usr/lib -fstack-protector >>> LDADD: >>>> >>>> Somewhere this is getting screwed up, and I have yet to figure out >>>> where - when I do I'll pass it on, but meanwhile I figured a heads >>>> up is in order. >>> I'd forgotten to mention that I'm still rather newb for this kind of >>> diagnosis, so help here would very much be appreciated :-) >> Building with heimdal-base (can't do ports): >> >> httpd: Syntax error on line 169 of >> /usr/local/etc/apache24/httpd.conf: Cannot load >> libexec/apache24/mod_auth_kerb.so into server: >> /usr/local/libexec/apache24/mod_auth_kerb.so: Undefined symbol >> "krb5_gss_register_acceptor_identity" > Similar error was reported here in 2015: > https://forums.freebsd.org/threads/apache-2-4-not-working-with-mod_auth_kerb2.52825/ > > readelf -Ws /usr/local/lib/libkrb5.so | grep krb5_rc_dfl_init > 1422: 000000000007c7b0 234 FUNC GLOBAL DEFAULT 11 > krb5_rc_dfl_init > > readelf -Ws /usr/lib/libkrb5.so | grep krb5_rc_dfl_init > > readelf -Ws /usr/local/lib/libkrb5.so | grep > krb5_gss_register_acceptor_identity > > readelf -Ws /usr/lib/libkrb5.so | grep > krb5_gss_register_acceptor_identity > > Notice that neither heimdal-base or mit krb5 have > krb5_gss_register_acceptor_identity. So where is that coming from? I > also checked most other libs (libkrb5.so, libgssapi_krb5.so, > libheimbase.so, libheimntlm.so, libgssapi_ntlm.so, > libgssapi_spnego.so, etc) required with no success. > > And now I believe I may be officially out of my depth, as this seems > to be a path order issue in the linking process. > > Anyone shed some light here? Had some help on the irc ports channel, but this has a fix: apxs (system specific) holds some builtin variables (check apxs -q) which can be (may need to be) overridden. Line 16 of the Makefile found in work/ should read like this: ./apxs.sh "${CPPFLAGS}" "${LDFLAGS}" "${SPNEGO_SRCS}" "${APXS}" "-S LDFLAGS=-L/usr/local/lib -c" "src/mod_auth_kerb.c" apxs -q reveals that LDFLAGS=-L/usr/lib -fstack-protector, but can't seem to append that to the override. This probably explains why runtime errors can be rather hit and miss - if apxs changes, then that likely breaks the port. This fix is only for mit-krb5; heimdal has another issue - I suspect its looking for mit-krb5, but regardless whatever it is looking for doesn't exist. I'll put up a PR, but I can't exactly offer a patch per se as I'm not 100% sure of the lack of the other components of LDFLAGS found in apxs.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9b6c9970-6c44-921d-7ff9-45712b86119c>