Q: RUNPATH missing in libsmbldap.so but not other executables/libraries?

[Alexander Bokovoy]

On to, 19 touko 2022, Michael Tokarev via samba-technical wrote:
> 13.05.2022 12:35, Michael Tokarev via samba-technical wrote:
> > Hi!
> > 
> > In debian we've got a bugreport about one of the samba libraries missing RUNPATH
> > to the private library directory (where libreplace-sambae.so libsmbd-shim-samba4.so
> > etc are located.  This one is libsmbldap.so.2.1.0. And indeed, unlike all other
> > libs and executables, this one lacks RUNPATH section, while all other binaries
> > does have it.
> > 
> > $ ldd /usr/lib/x86_64-linux-gnu/libsmbldap.so.2.1.0 | grep found
> >      libsamba-debug-samba4.so.0 => not found
> >      libreplace-samba4.so.0 => not found
> >      libsamba-security-samba4.so.0 => not found
> >      libsmbd-shim-samba4.so.0 => not found
> 
> source3/wscript_build:
> 
> bld.SAMBA3_LIBRARY('smbldap',
>                     source='lib/smbldap.c',
>                     deps='ldap lber samba-util smbconf',
> 
> All 4 of these are not marked as "private".
> 
> buildtools/wafsamba/samba_utils.py:install_rpath() only list private
> libdir if at least one of the dependencies is marked as private.
> 
> but since libsmbldap is actually uses symbols from other libraries,
> as determined by the linker (all these are listed in NEEDED section),
> it seems logical to include these in the dependencies. So after this:
> 
>  bld.SAMBA3_LIBRARY('smbldap',
>                      source='lib/smbldap.c',
> -                    deps='ldap lber samba-util smbconf',
> +                    deps='ldap lber samba-util smbconf replace samba-debug samba-security',
> 
> it builds fine *and* includes the private library path in the resulting
> library, so that ldd etc is actually able to find the above 4 deps
> too.
> 
> I don't know (yet) about smbd-shim which is also needed by libsmbldap
> but which is not a usual library.  But this is enough already to fix
> the underlying issue (of binaries being unable to find their dependencies).

smbd and other daemons that load smbldap link to those four missing
libraries, so there is no problem for them in real life. On Fedora we
have it this way:

[root at dc ~]# ldd /usr/sbin/smbd|grep security
	libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so (0x00007f21bc859000)
[root at dc ~]# ldd /usr/lib64/libsmbldap.so.2.1.0 |grep security
	libsamba-security-samba4.so => not found
	libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so (0x00007f8e3ee0a000)

If smbldap is actually using those symbols, chances are that
dependencies weren't fixed when their use was added in the code, so
fixing dependencies now is reasonable.

Please submit a merge request that adds them, same for the libraries
below.

> 
> The same is true for other libs which are also missing private libs
> directory in their RUNPATH:
> 
> File: /usr/lib/x86_64-linux-gnu/samba/libads-samba4.so.0
> File: /usr/lib/x86_64-linux-gnu/samba/libnet-keytab-samba4.so.0
> File: /usr/lib/x86_64-linux-gnu/samba/libsamba-modules-samba4.so.0
> File: /usr/lib/x86_64-linux-gnu/samba/libsmbldaphelper-samba4.so.0
> 
> adding their corresponding dependencies in wscripts fixes the issue.
> 
> Looking at the whole picture, it seems like the dependency problem
> in samba is *huge*, there's just a few libs which gets their deps
> correctly, vast majority of them are wrong. I don't know if it is
> worth fixing this mess, -- at least it should be done by someone
> who knows the thing just a bit.

Samba went through at least three or four build systems during past two
decades exactly because we had a need to express complex dependencies we
have. At some point there was a library called bigballofmud that simply
linked all the pieces needed for smbd. WAF expressions allow to solve
most of those problems now but they aren't a replacement for the cases
when code morphs and gets refactored/moved between components. Human
intervention is still needed.

> 
> I'm fixing this in debian, but I'm not submitting a patch to samba,
> since it's just a waste of my time.

No, please submit them upstream because otherwise it is going to be
waste of your time every time this happens.


-- 
/ Alexander Bokovoy