mod_auth_kerb2 causes apache to fail to start

Wed Feb 28 13:19:50 UTC 2018

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.