When I build sssd from source, I specify "--with-crypto=libcrypto" during configure stage, however during the build and install stage, sssd is linked with both libcrypto.so and libnss3.so+libnssutil3.so
Is there a way to completely disable all Mozilla NSS libraries with sssd?
On Tue, Jan 14, 2020 at 11:37:58AM -0000, Sad Clouds wrote:
When I build sssd from source, I specify "--with-crypto=libcrypto" during configure stage, however during the build and install stage, sssd is linked with both libcrypto.so and libnss3.so+libnssutil3.so
Is there a way to completely disable all Mozilla NSS libraries with sssd?
Hi,
"--with-crypto=libcrypto" should only use OpenSSL's libcrypto.so.
Can you give some more details, e.g. which version of SSSD you try to build on which platform?
E.g. the Fedora packages are built with OpenSSL only, you can check the dependencies e.g. at https://koji.fedoraproject.org/koji/rpminfo?rpmID=19411315 for the SSSD AD provider.
Is there a chance that some of the libraries SSSD depends on is build with NSS on you platform?
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Sure
On CentOS-7 SSSD installed via yum: $ rpm -q sssd sssd-1.16.4-21.el7.x86_64
$ sssd --version 1.16.4
$ ldd /sbin/sssd | grep -e nss -e crypto libnss3.so => /lib64/libnss3.so (0x00007f4928ccc000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f4928a9c000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f4927dd7000)
On CentOS-7 SSSD built and installed by hand from source: # /opt/sssd/usr/sbin/sssd --version 2.2.2
# ldd /opt/sssd/usr/sbin/sssd | grep -e nss -e crypto libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8bd6e54000) libnss3.so => /lib64/libnss3.so (0x00007f8bd4ee0000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f8bd4cb0000)
As you can see in both versions SSSD is linked against OpenSSL libcrypto and Mozilla libnss libraries.
I disabled as much as I could, I'm only interested in LDAP authentication and nothing less, still for some reason SSSD binary is linked with Mozilla NSS, as well as OpenSSL
# grep 'with-crypto' config.log $ ./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var --with-crypto=libcrypto --enable-nsslibdir=/lib64 --enable-pammoddir=/lib64/security --disable-krb5-locator-plugin --disable-cifs-idmap-plugin --without-nfsv4-idmapd-plugin --disable-pac-responder --disable-nls --without-python2-bindings --without-python3-bindings --without-autofs --without-samba --without-kcm --without-selinux --without-semanage --without-manpages --without-libwbclient
Any ideas?
On (14/01/20 12:21), Sad Clouds wrote:
Sure
On CentOS-7 SSSD installed via yum: $ rpm -q sssd sssd-1.16.4-21.el7.x86_64
$ sssd --version 1.16.4
$ ldd /sbin/sssd | grep -e nss -e crypto libnss3.so => /lib64/libnss3.so (0x00007f4928ccc000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f4928a9c000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f4927dd7000)
That's not ideal test. Becasue ldd does not sove just direct dependencies but all dependencies. And libldap is linked with nss on el7.
sh# ldd /usr/lib64/libldap-2.4.so.2 | grep nss libnss3.so => /lib64/libnss3.so (0x00007f01fc148000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f01fbf18000)
sh# ldd /usr/lib64/libldap-2.4.so.2 linux-vdso.so.1 => (0x00007ffc88281000) liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007fd18c33b000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd18c122000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007fd18bf05000) libssl.so.10 => /lib64/libssl.so.10 (0x00007fd18bc93000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fd18b830000) libssl3.so => /lib64/libssl3.so (0x00007fd18b5d7000) libsmime3.so => /lib64/libsmime3.so (0x00007fd18b3af000) libnss3.so => /lib64/libnss3.so (0x00007fd18b080000) libnssutil3.so => /lib64/libnssutil3.so (0x00007fd18ae50000) libplds4.so => /lib64/libplds4.so (0x00007fd18ac4c000) libplc4.so => /lib64/libplc4.so (0x00007fd18aa47000) libnspr4.so => /lib64/libnspr4.so (0x00007fd18a809000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd18a5ed000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fd18a3e9000) libc.so.6 => /lib64/libc.so.6 (0x00007fd18a01b000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fd189de4000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fd189b97000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fd1898ae000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fd18967b000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fd189477000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fd189267000) libz.so.1 => /lib64/libz.so.1 (0x00007fd189051000) librt.so.1 => /lib64/librt.so.1 (0x00007fd188e49000) /lib64/ld-linux-x86-64.so.2 (0x00007fd18c79f000) libfreebl3.so => /lib64/libfreebl3.so (0x00007fd188c46000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fd188a42000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd18881b000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fd1885b9000)
sh# objdump -p /usr/lib64/libldap-2.4.so.2 | grep NEEDED NEEDED liblber-2.4.so.2 NEEDED libresolv.so.2 NEEDED libsasl2.so.3 NEEDED libssl.so.10 NEEDED libcrypto.so.10 NEEDED libssl3.so NEEDED libsmime3.so NEEDED libnss3.so NEEDED libnssutil3.so NEEDED libplds4.so NEEDED libplc4.so NEEDED libnspr4.so NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libc.so.6
sh# objdump -p /usr/lib64/libldap-2.4.so.2 | grep NEEDED | wc -l 15 sh# ldd /usr/lib64/libldap-2.4.so.2 | wc -l 29
LS
Hi Lukas, as far as I can see, /sbin/sssd binary does not depend on libldap at all. If you run "ldd -v /sbin/sssd" it will show you which libraries pull in libnss3:
It looks like libsss_cert.so, libsss_crypt.so, libsss_certmap.so.0 are all part of SSSD but directly link with libnss3. Why is that when I specifically asked for "--with-crypto=libcrypto"?
/usr/lib64/sssd/libsss_cert.so: libsss_certmap.so.0 (SSS_CERTMAP_0.0) => /lib64/libsss_certmap.so.0 libtevent.so.0 (TEVENT_0.9.9) => /lib64/libtevent.so.0 libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 libtalloc.so.2 (TALLOC_2.0.2) => /lib64/libtalloc.so.2 libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0 libnss3.so (NSS_3.12) => /lib64/libnss3.so libnss3.so (NSS_3.2) => /lib64/libnss3.so /usr/lib64/sssd/libsss_crypt.so: libnssutil3.so (NSSUTIL_3.12.5) => /lib64/libnssutil3.so libtalloc.so.2 (TALLOC_2.0.2) => /lib64/libtalloc.so.2 libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0 libcrypto.so.10 (libcrypto.so.10) => /lib64/libcrypto.so.10 libnss3.so (NSS_3.3) => /lib64/libnss3.so libnss3.so (NSS_3.10) => /lib64/libnss3.so libnss3.so (NSS_3.4) => /lib64/libnss3.so libnss3.so (NSS_3.2) => /lib64/libnss3.so /usr/lib64/sssd/libsss_child.so: libdhash.so.1 (DHASH_0.4.3) => /lib64/libdhash.so.1 libtalloc.so.2 (TALLOC_2.0.2) => /lib64/libtalloc.so.2 libtevent.so.0 (TEVENT_0.9.9) => /lib64/libtevent.so.0 libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 /lib64/libsss_certmap.so.0: libnssutil3.so (NSSUTIL_3.12) => /lib64/libnssutil3.so libtalloc.so.2 (TALLOC_2.0.2) => /lib64/libtalloc.so.2 libnss3.so (NSS_3.4) => /lib64/libnss3.so libnss3.so (NSS_3.8) => /lib64/libnss3.so libnss3.so (NSS_3.12.5) => /lib64/libnss3.so libnss3.so (NSS_3.9) => /lib64/libnss3.so libnss3.so (NSS_3.2.1) => /lib64/libnss3.so libnss3.so (NSS_3.3) => /lib64/libnss3.so libnss3.so (NSS_3.12) => /lib64/libnss3.so libnss3.so (NSS_3.10) => /lib64/libnss3.so libnss3.so (NSS_3.2) => /lib64/libnss3.so libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 /lib64/libssl3.so: libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0 libnssutil3.so (NSSUTIL_3.12.5) => /lib64/libnssutil3.so libnssutil3.so (NSSUTIL_3.12.3) => /lib64/libnssutil3.so libnssutil3.so (NSSUTIL_3.24) => /lib64/libnssutil3.so libnssutil3.so (NSSUTIL_3.15) => /lib64/libnssutil3.so libnssutil3.so (NSSUTIL_3.12) => /lib64/libnssutil3.so libnss3.so (NSS_3.14) => /lib64/libnss3.so libnss3.so (NSS_3.11.1) => /lib64/libnss3.so libnss3.so (NSS_3.4) => /lib64/libnss3.so libnss3.so (NSS_3.6) => /lib64/libnss3.so libnss3.so (NSS_3.11) => /lib64/libnss3.so libnss3.so (NSS_3.10) => /lib64/libnss3.so libnss3.so (NSS_3.15) => /lib64/libnss3.so libnss3.so (NSS_3.8) => /lib64/libnss3.so libnss3.so (NSS_3.19.1) => /lib64/libnss3.so libnss3.so (NSS_3.11.2) => /lib64/libnss3.so libnss3.so (NSS_3.9) => /lib64/libnss3.so libnss3.so (NSS_3.12) => /lib64/libnss3.so libnss3.so (NSS_3.22) => /lib64/libnss3.so libnss3.so (NSS_3.12.6) => /lib64/libnss3.so libnss3.so (NSS_3.3) => /lib64/libnss3.so libnss3.so (NSS_3.14.3) => /lib64/libnss3.so libnss3.so (NSS_3.2) => /lib64/libnss3.so libnss3.so (NSS_3.21) => /lib64/libnss3.so /lib64/libsmime3.so: libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 libnssutil3.so (NSSUTIL_3.12) => /lib64/libnssutil3.so libnss3.so (NSS_3.11.1) => /lib64/libnss3.so libnss3.so (NSS_3.10) => /lib64/libnss3.so libnss3.so (NSS_3.7) => /lib64/libnss3.so libnss3.so (NSS_3.11) => /lib64/libnss3.so libnss3.so (NSS_3.6) => /lib64/libnss3.so libnss3.so (NSS_3.3.1) => /lib64/libnss3.so libnss3.so (NSS_3.8) => /lib64/libnss3.so libnss3.so (NSS_3.9) => /lib64/libnss3.so libnss3.so (NSS_3.12) => /lib64/libnss3.so libnss3.so (NSS_3.4) => /lib64/libnss3.so libnss3.so (NSS_3.2) => /lib64/libnss3.so libnss3.so (NSS_3.21) => /lib64/libnss3.so libnss3.so (NSS_3.3) => /lib64/libnss3.so
On (14/01/20 13:33), Sad Clouds wrote:
Hi Lukas, as far as I can see, /sbin/sssd binary does not depend on libldap at all. If you run "ldd -v /sbin/sssd" it will show you which libraries pull in libnss3:
I have no idea how did you build and copy/install sssd yourself on CentOS & but I cannot reproduce it.
I used the same configure paramets as you + standard make way to isntall binaries
./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var --with-crypto=libcrypto --enable-nsslibdir=/lib64 --enable-pammoddir=/lib64/security --disable-krb5-locator-plugin --disable-cifs-idmap-plugin --without-nfsv4-idmapd-plugin --disable-pac-responder --disable-nls --without-python2-bindings --without-python3-bindings --without-autofs --without-samba --without-kcm --without-selinux --without-semanage --without-manpages --without-libwbclient && make && sudo make install
[root@host sssd-2.2.4]# ldd /usr/lib64/sssd/ | grep nss conf/ libsss_cert.la libsss_crypt.so libsss_iface.la libsss_krb5.so libsss_ldap_common.la libsss_sbus.so libsss_simple.la libifp_iface.la libsss_cert.so libsss_debug.la libsss_iface.so libsss_krb5_common.la libsss_ldap_common.so libsss_sbus_sync.la libsss_simple.so libifp_iface.so libsss_child.la libsss_debug.so libsss_iface_sync.la libsss_krb5_common.so libsss_proxy.la libsss_sbus_sync.so libsss_util.la libifp_iface_sync.la libsss_child.so libsss_files.la libsss_iface_sync.so libsss_ldap.la libsss_proxy.so libsss_semanage.la libsss_util.so libifp_iface_sync.so libsss_crypt.la libsss_files.so libsss_krb5.la libsss_ldap.so libsss_sbus.la libsss_semanage.so modules/ [root@host sssd-2.2.4]# ldd /usr/lib64/sssd/libsss_ldap_common.so | grep nss libnss3.so => /lib64/libnss3.so (0x00007f037e3d6000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f037e1a6000) [root@host sssd-2.2.4]# objdump -p /usr/lib64/sssd/libsss_ldap_common.so | grep NEED NEEDED liblber-2.4.so.2 NEEDED libldap-2.4.so.2 NEEDED libsss_krb5_common.so NEEDED libkeyutils.so.1 NEEDED libkrb5.so.3 NEEDED libk5crypto.so.3 NEEDED libcom_err.so.2 NEEDED libsss_idmap.so.0 NEEDED libsss_util.so NEEDED librt.so.1 NEEDED libpopt.so.0 NEEDED libldb.so.1 NEEDED libdbus-1.so.3 NEEDED libtdb.so.1 NEEDED libglib-2.0.so.0 NEEDED libpcre.so.1 NEEDED libini_config.so.3 NEEDED libbasicobjects.so.0 NEEDED libref_array.so.1 NEEDED libcollection.so.2 NEEDED libsss_cert.so NEEDED libsss_certmap.so.0 NEEDED libsss_crypt.so NEEDED libcrypto.so.10 NEEDED libsss_child.so NEEDED libtevent.so.0 NEEDED libtalloc.so.2 NEEDED libdhash.so.1 NEEDED libsss_debug.so NEEDED libdl.so.2 NEEDED libc.so.6 VERNEED 0x0000000000008968 VERNEEDNUM 0x0000000000000008 [root@host sssd-2.2.4]# objdump -p /usr/lib64/sssd/libsss_ldap_common.so | grep NSS [root@host sssd-2.2.4]#
and /usr/lib64/sssd/libsss_ldap_common.so is still indirectly linked with NSS crypto due to libldap-2.4.so.2 :=)
HTH
BTW I had bot nss and openssl headers installed on the system
LS
I don't know if there was a formatting issue, but "ldd /usr/lib64/sssd/ | grep nss" makes no sense, because you're running ldd on a directory. And then if you grep for nss, why does it print a bunch of lines that don't contain nss string in it?
Are you running the build on CentOS-7 as well, or some other platform?
What do you get if you build with sssd-2.2.3 as this is what I'm using since this is the latest stable release.
On (14/01/20 14:43), Sad Clouds wrote:
I don't know if there was a formatting issue, but "ldd /usr/lib64/sssd/ | grep nss" makes no sense, because you're running ldd on a directory. And then if you grep for nss, why does it print a bunch of lines that don't contain nss string in it?
Just copy and paste issues.
Are you running the build on CentOS-7 as well, or some other platform?
yes, CentOS-7
What do you get if you build with sssd-2.2.3 as this is what I'm using since this is the latest stable release.
The same results as for master.
I cannot reproduce your results and /usr/lib64/sssd/libsss_crypt.so is not linked with NSS
LS
OK, on Fedora 31 I can see SSSD does not link against Mozilla NSS, so Lucas was probably correct about /usr/lib64/libldap-2.4.so.2 pulling in Mozilla NSS.
sssd-users@lists.fedorahosted.org