2010-03-28 01:48:49 +03:00
#!/usr/bin/env python
2018-02-02 17:34:31 +03:00
from waflib import Utils
2012-10-02 02:12:16 +04:00
import sys
host_os = sys.platform
2010-03-28 01:48:49 +03:00
2010-03-17 14:07:42 +03:00
bld.SAMBA_BINARY('nsstest',
2012-11-21 13:20:46 +04:00
source='nsstest.c',
deps='replace dl',
2019-11-22 00:06:57 +03:00
for_selftest=True
2012-11-21 13:20:46 +04:00
)
2010-03-17 14:07:42 +03:00
2018-10-05 14:53:30 +03:00
if bld.CONFIG_SET('HAVE_PTHREAD'):
bld.SAMBA_BINARY('stress-nss-libwbclient',
source='stress-nss-libwbclient.c',
2019-10-15 13:52:42 +03:00
deps='wbclient pthread',
2019-11-22 00:06:57 +03:00
for_selftest=True
2018-10-05 14:53:30 +03:00
)
2012-10-03 10:36:34 +04:00
# The nss_wrapper code relies strictly on the linux implementation and
# name, so compile but do not install a copy under this name.
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('nss_wrapper_winbind',
2021-07-01 13:08:16 +03:00
cflags='-D_PUBLIC_ON_LINUX_=_PUBLIC_',
2012-10-03 10:36:34 +04:00
source='winbind_nss_linux.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='wbclient',
2012-10-03 10:36:34 +04:00
realname='libnss_wrapper_winbind.so.2',
install=False,
vnum='2')
2012-10-02 02:12:16 +04:00
# FIXME: original was *linux* | gnu* | k*bsd*-gnu | kopensolaris*-gnu)
# the search for .rfind('gnu') covers gnu* and *-gnu is that too broad?
if (Utils.unversioned_sys_platform() == 'linux' or (host_os.rfind('gnu') > -1)):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('nss_winbind',
2014-12-18 12:33:34 +03:00
keep_underscore=True,
2021-07-01 13:08:16 +03:00
cflags='-D_PUBLIC_ON_LINUX_=_PUBLIC_',
2014-12-18 12:33:34 +03:00
source='winbind_nss_linux.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='wbclient',
realname='libnss_winbind.so.2',
soname='libnss_winbind.so.2',
2014-12-18 12:33:34 +03:00
vnum='2')
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA3_PLUGIN('nss_wins',
keep_underscore=True,
cflags='-D_PUBLIC_ON_LINUX_=_PUBLIC_',
source='wins.c',
deps='wbclient replace',
realname='libnss_wins.so.2',
soname='libnss_wins.so.2',
vnum='2')
2012-10-02 02:12:16 +04:00
elif (host_os.rfind('freebsd') > -1):
# FreeBSD winbind client is implemented as a wrapper around
# the Linux version.
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('nss_winbind',
2012-10-02 02:12:16 +04:00
source='winbind_nss_linux.c winbind_nss_freebsd.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='wbclient',
2013-03-08 05:36:37 +04:00
realname='nss_winbind.so.1',
2012-10-02 02:12:16 +04:00
vnum='1')
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA3_PLUGIN('nss_wins',
2015-09-10 12:27:42 +03:00
source='wins.c wins_freebsd.c',
2015-10-23 13:31:43 +03:00
deps='''wbclient''',
2015-09-10 12:27:42 +03:00
realname='nss_wins.so.1',
vnum='1')
2012-10-02 02:12:16 +04:00
elif (host_os.rfind('netbsd') > -1):
# NetBSD winbind client is implemented as a wrapper
# around the Linux version. It needs getpwent_r() to
# indicate libc's use of the correct nsdispatch API.
2012-09-30 23:02:13 +04:00
2012-10-02 02:12:16 +04:00
if bld.CONFIG_SET("HAVE_GETPWENT_R"):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('nss_winbind',
2012-10-02 02:12:16 +04:00
source='winbind_nss_linux.c winbind_nss_netbsd.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='wbclient',
2012-10-02 02:12:16 +04:00
realname='libnss_winbind.so')
elif Utils.unversioned_sys_platform() == 'sunos':
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('nss_winbind',
2012-10-02 02:12:16 +04:00
source='winbind_nss_solaris.c winbind_nss_linux.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='wbclient',
2012-10-02 02:12:16 +04:00
realname='nss_winbind.so.1',
vnum='1')
elif (host_os.rfind('hpux') > -1):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('nss_winbind',
2012-10-02 02:12:16 +04:00
source='winbind_nss_linux.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='wbclient',
2012-10-02 02:12:16 +04:00
realname='libnss_winbind.so')
elif (host_os.rfind('aix') > -1):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('nss_winbind',
2012-10-02 02:12:16 +04:00
source='winbind_nss_aix.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='wbclient',
2014-06-12 12:29:47 +04:00
realname='WINBIND')
2011-02-17 02:11:18 +03:00
2011-05-08 23:50:34 +04:00
if bld.CONFIG_SET('WITH_PAM_MODULES') and bld.CONFIG_SET('HAVE_PAM_START'):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('pamwinbind',
2011-02-17 02:11:18 +03:00
source='pam_winbind.c',
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
deps='talloc wbclient tiniparser pam samba_intl',
2010-10-24 03:23:53 +04:00
cflags='-DLOCALEDIR=\"%s/locale\"' % bld.env.DATADIR,
realname='pam_winbind.so',
2011-09-06 11:39:16 +04:00
install_path='${PAMMODULESDIR}'
2010-10-24 03:23:53 +04:00
)
2011-02-17 02:11:18 +03:00
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
if bld.CONFIG_GET("USING_SYSTEM_KRB5"):
# If we build locator plugins for a
# system library we should use builtin
# linking of our own subsystems,
# while we may link to the system
# krb5 libraries.
winbind_krb5_require_builtin_deps = True
else:
# If we build locator plugins for our own heimdal
# version we don't want to do builtin linking.
# As we're already using private libraries
# it's not a problem...
winbind_krb5_require_builtin_deps = False
2011-02-17 02:11:18 +03:00
if bld.CONFIG_SET('HAVE_KRB5_LOCATE_PLUGIN_H'):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('winbind_krb5_locator',
source='krb5_plugin/winbind_krb5_locator.c',
deps='wbclient krb5 com_err',
require_builtin_deps=winbind_krb5_require_builtin_deps,
realname='winbind_krb5_locator.so',
install_path='${MODULESDIR}/krb5')
2011-02-17 02:43:05 +03:00
2020-09-25 23:42:46 +03:00
if bld.CONFIG_SET('HAVE_KRB5_LOCATE_PLUGIN_H'):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
# libkrb5.so scans it's plugin directories for files
# and calls dlopen()/dlsym() on them. The actual path
# depends on MIT vs. Heimdal.
#
# The async_dns_krb5_locator don't use winbind,
# instead it uses almost all of samba directly,
# which means everything will be injected
# into all processes using the libkrb5.so.
#
# See https://bugzilla.samba.org/show_bug.cgi?id=14780
# why this is a bad idea.
#
# We install this plugin (and also the other krb5 plugins)
# under Samba's MODULESDIR, it's not available to
# libkrb5.so by default.
#
# Packagers should leave it that way and allow admins
# to create symlinks for the plugins they actually want
# to be used.
bld.SAMBA_PLUGIN('async_dns_krb5_locator',
source='krb5_plugin/async_dns_krb5_locator.c',
deps='''
talloc
addns
samba_intl
libsmb
smbconf
KRBCLIENT
smbd_base
krb5
com_err
''',
require_builtin_deps=False,
realname='async_dns_krb5_locator.so',
install_path='${MODULESDIR}/krb5')
2020-09-25 23:42:46 +03:00
2018-06-15 15:59:00 +03:00
if bld.CONFIG_SET('HAVE_KRB5_LOCALAUTH_PLUGIN_H'):
nsswitch: reduce dependecies to private libraries and link static/builtin if possible
Over the last month I got more and more reports,
that it's not possible to use a custom Samba version
on systems with sssd being installed, which depends on some
specific samba libraries installed in the system.
One major problem is that the custom libnss_winbind.so.2
depends on the libreplace-samba4.so of the custom build
and also injects an RPATH into the running process.
When sssd uses any nss library call it will get this,
when it then tries to load some of its plugins via dlopen(),
e.g.
ldd /usr/lib64/sssd/libsss_ad.so| grep samba
libsamba-util.so.0 => /lib64/libsamba-util.so.0
libreplace-samba4.so => /usr/lib64/samba/libreplace-samba4.so
libsamba-security-samba4.so => /usr/lib64/samba/libsamba-security-samba4.so
libsamba-errors.so.1 => /lib64/libsamba-errors.so.1
libsamba-debug-samba4.so => /usr/lib64/samba/libsamba-debug-samba4.so
libgenrand-samba4.so => /usr/lib64/samba/libgenrand-samba4.so
libsocket-blocking-samba4.so => /usr/lib64/samba/libsocket-blocking-samba4.so
libtime-basic-samba4.so => /usr/lib64/samba/libtime-basic-samba4.so
libsys-rw-samba4.so => /usr/lib64/samba/libsys-rw-samba4.so
libiov-buf-samba4.so => /usr/lib64/samba/libiov-buf-samba4.so
When that loads dlopen() will fail as a soname libreplace-samba4.so is
already loaded, but the symbol version within the other one don't match, as the
contain the exact version, e.g. replace_dummy@@SAMBA_4.13.3.
This is just an example and similar things can happen in all situations
where we provide libraries, which are potentially injected into every
process of the running system. These should only depend on libc.so and
related basic system libraries in order to avoid the problem.
We have the following libraries, which are in the that category:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
- async_dns_krb5_locator.so
The rules of library loading are really complex and symbol versioning
is not enough to solve it, only the combination of unique soname and
unique symbol version suffix seem to solve the problem, but injecting
an RPATH is still a problem.
In order to solve the problem I experimented with adding SAMBA_SUBSYSTEM()
definitions with 'hide_symbols=True' in order to do some static linking
of selected components, e.g.
bld.SAMBA_SUBSYSTEM('replace-hidden',
source=REPLACE_SOURCE,
group='base_libraries',
hide_symbols=True,
deps='dl attr' + extra_libs)
It's relatively simple to get to the point where the following are
completely static:
- libnss_winbind.so.2
- libnss_wins.so.2
- pam_winbind.so
- winbind_krb5_locator.so
But 'async_dns_krb5_locator.so' links in almost everything!
It seems we install the krb5 plugins into our own $MODULESDIR/krb5/,
so it may not be so critical, as long it's the admin who created
the desired symlinks into the location the kerberos libraries search
for plugins. Note the at least the locator plugins are always loaded
without any configuration, every .so in a special path are loaded with dlopen().
This is done by every application using kerberos, so we load a lot of samba libraries
into them.
Packagers should not put async_dns_krb5_locator.so (nor a symlink) into
the path that's reachable by libkrb5.so.
As a longterm solution we may want to change async_dns_krb5_locator.so
to use a helper process with posix_spawn() instead of doing everything
within the process.
Note I added hiden_symbols=True to the nss modules for Linux and
FreeBSD only, because these are the only platforms I'm able to test
on. We most likely should do the same on other platforms, but some
with access to the platform should provide a tested patch.
In order to avoid manual definitions of SAMBA_SUBSYSTEMS() with
'-hidden', I added the 'provide_builtin_linking=True' option,
as the logic is very similar to what we already have with the
'--builtin-libraries=BUILTIN_LIBRARIES' configure option.
SAMBA_PLUGIN() is used in order to use SAMBA_LIBRARY() in order
to make it more strict that these plugins can't be used as
normal depedency by other subsystems and libraries.
While being there it was easy enough to make libwbclient.so
also standalone without dependecies to other samba libraries.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14780
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
2021-07-01 13:08:16 +03:00
bld.SAMBA_PLUGIN('winbind_krb5_localauth',
source='krb5_plugin/winbind_krb5_localauth.c',
deps='wbclient krb5 com_err',
require_builtin_deps=winbind_krb5_require_builtin_deps,
realname='winbind_krb5_localauth.so',
install_path='${MODULESDIR}/krb5')
2018-06-15 15:59:00 +03:00
2011-02-17 02:43:05 +03:00
bld.SAMBA_SUBSYSTEM('WB_REQTRANS',
source='wb_reqtrans.c',
deps='talloc tevent LIBASYNC_REQ'
)
2011-10-08 04:19:35 +04:00
bld.SAMBA_BINARY('wbinfo',
source='wbinfo.c',
2021-01-14 12:53:35 +03:00
deps='samba-util LIBCLI_AUTH popt cmdline wbclient LIBAFS_SETTOKEN'
2011-10-08 04:19:35 +04:00
)
