IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This comment originally referred, not to a va_copy() call, but to the
use of &c with vsnprintf() rather than passing in NULL with a length of
zero.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Also fix an obsolete related comment.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Fri Feb 17 14:52:26 UTC 2023 on atb-devel-224
Removes:
* waf pydoctor
* waf wafdocs
* make pydoctor
There is no "make wafdocs" it only appears to be in wscript.
The reasoning being is these are broken and appear to not have been run for some time.
Signed-off-by: Rob van der Linde <rob@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Feb 2 21:15:54 UTC 2023 on atb-devel-224
Ensuring pointers are always initialised avoids compilation errors with
FORTIFY_SOURCE=2.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
I wanted to use this in debug.c, but this would have meant to pollute
debug's deps with a lot of stuff. Also, looking through uses of
talloc_asprint_append(), very many of those don't do NULL checks
properly and could benefit from the _addbuf() flavor. We can add a
vasprintf variant later if the need shows up.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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>
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
pytalloc is currently GPL, while the rest of talloc is LGPL.
This situation arose because pytalloc was originally developed under
source4/scripting/python/, and moved into talloc proper with commit
0f043c197c ("Move pytalloc to talloc
directory.", October 2008).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=9931
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jelmer Vernooij <jelmer@samba.org>
Reviewed-by: Björn Jacke <bjacke@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Mar 16 18:17:43 UTC 2021 on sn-devel-184
This is now never set, and also never tested, and only makes
the talloc code more complicated.
Once this is gone we can start looking at the memlimit
stuff.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Solaris Studio compiler 12.4 is pedantic about prototypes in headers having
the external visibility declarations too. It throws errors like:
redeclaration must have the same or more restrictive linker scoping: ...
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Solaris Studio compiler 12.4 is pedantic about prototypes in headers having
the external visibility declarations too. It throws errors like:
redeclaration must have the same or more restrictive linker scoping: ...
Signed-off-by: Bjoern Jacke <bjacke@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This requires the previous patch.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14540
Signed-off-by: Arran Cudbard-Bell <a.cudbardb@freeradius.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We only have to do the memlimit check before any
real malloc or realloc. Allocations out of a
memory pool have already been counted in the
memory limit, so don't check in those cases.
This is an application-visible change (although
fixing a bug) so bump the ABI to 2.3.1 -> 2.3.2.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14540
Signed-off-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Arran Cudbard-Bell <a.cudbardb@freeradius.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
tc_alloc_pool() or the fallback malloc can return NULL.
Wait until we know we are returning a valid pointer
before decrementing pool_hdr->object_count due to
reallocing out of the talloc_pool.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14540
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
* Upgrade waf to 2.0.18 to fix a cross-compilation issue
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13846
Signed-off-by: Uri Simchoni <uri@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Fixes:
ib/talloc/pytalloc_util.c:245:8: warning: Value stored to 'type_obj' during its initialization is never read <--[clang]
void *type_obj = talloc_check_name(ptr, type_name);
^~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Direct leak of 1152 byte(s) in 1 object(s) allocated from:
#0 0x7f06393dfc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f06392cfd59 in __talloc_with_prefix ../../talloc.c:782
#2 0x7f06392cfd59 in _talloc_pool ../../talloc.c:837
#3 0x7f06392cfd59 in talloc_pool ../../talloc.c:859
#4 0x40b83c in test_magic_protection ../../testsuite.c:1960
#5 0x40b83c in torture_local_talloc ../../testsuite.c:2164
#6 0x402603 in main ../../testsuite_main.c:32
#7 0x7f063908a412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Direct leak of 100 byte(s) in 1 object(s) allocated from:
#0 0x7f06393dfc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f06392d1af3 in __talloc_with_prefix ../../talloc.c:782
#2 0x7f06392d1af3 in __talloc ../../talloc.c:824
#3 0x7f06392d1af3 in __talloc_strlendup ../../talloc.c:2455
#4 0x7f06392d1af3 in talloc_strdup ../../talloc.c:2471
#5 0x40b4f0 in test_rusty ../../testsuite.c:1543
#6 0x40b4f0 in torture_local_talloc ../../testsuite.c:2146
#7 0x402603 in main ../../testsuite_main.c:32
#8 0x7f063908a412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7f06393dfc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7f06392d0c45 in __talloc_with_prefix ../../talloc.c:782
#2 0x7f06392d0c45 in __talloc ../../talloc.c:824
#3 0x7f06392d0c45 in _talloc_named_const ../../talloc.c:981
#4 0x7f06392d0c45 in talloc_named_const ../../talloc.c:1748
#5 0x40901e in test_pool_nest ../../testsuite.c:1451
#6 0x40901e in torture_local_talloc ../../testsuite.c:2096
#7 0x402603 in main ../../testsuite_main.c:32
#8 0x7f063908a412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7fd52c00dc08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x7fd52befec45 in __talloc_with_prefix ../../talloc.c:782
#2 0x7fd52befec45 in __talloc ../../talloc.c:824
#3 0x7fd52befec45 in _talloc_named_const ../../talloc.c:981
#4 0x7fd52befec45 in talloc_named_const ../../talloc.c:1748
#5 0x4099bd in test_realloc_on_destructor_parent ../../testsuite.c:1000
#6 0x4099bd in torture_local_talloc ../../testsuite.c:2129
#7 0x402603 in main ../../testsuite_main.c:32
#8 0x7fd52bcb8412 in __libc_start_main (/lib64/libc.so.6+0x24412)
Signed-off-by: Swen Schillig <swen@linux.ibm.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
* add pytalloc_get_name() to safely access te talloc name in Python bindings
* Use a new minor version to allow talloc updates in the 4.11 release stream
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz
Being careful is good and all, but if we don't trust the
static PyTypeObject *type = NULL;
two lines up, we need to reconsider our entire software universe.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If the python object is not a talloc object, we will end up
with a NULL pointer. We weren't checking for that properly
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
In several places we go
talloc_get_name(pytalloc_get_ptr(py_obj))
which is a certain NULL derefernce if py_obj is not a talloc object.
This is a helper function that chooses to say "non-talloc object"
rather than crash.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We no longer need Samba to be py2/py3 compatible so we choose to return to the standard
function names.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Noel Power <noel.power@suse.com>
To avoid warning above produced by using
-Wcast-function-type we;
+ ensure PyCFunctions of type METH_NOARGS defined dummy arg
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andreas Schneider <asn@samba.org>
