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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The FreeBSD extattr API may return success and truncated
namelist. We need to check for this in bsd_attr_list to
ensure that we don't accidentally read off the end of the
buffer. In the case of a truncated value, the pascal
strings for attr names will reflect the lengths as if
the value were not truncated. For example:
`58DosStrea`
In case of short read we now set error to ERANGE and
fail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15271
Signed-off-by: Andrew Walker <awalker@ixsystems.com>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Mon Jan 2 14:27:23 UTC 2023 on sn-devel-184
(cherry picked from commit 01cdc5e00b)
Autobuild-User(v4-16-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-16-test): Mon Jan 23 10:59:28 UTC 2023 on sn-devel-184
This provides the defines that may be needed to use the
compiler-provided atomics, rather than a fallback.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
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>
We should not provide the symbols ourself instead we should just check
if they are already available when we want to check the result.
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: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Nov 17 05:27:39 UTC 2021 on sn-devel-184
This reverts commit 4354823c51
"libreplace: properly execute SYS_copy_file_range check".
We now use a runtime check in the user of copy_file_range().
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Sep 7 19:24:57 UTC 2021 on sn-devel-184
Pair-Programmed-With: Jeremy Allison <jra@samba.org>
Signed-off-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Aug 16 17:20:37 UTC 2021 on sn-devel-184
The only user was removed in the previous commit. We still need the preceeding
checks however, based on that replace.c provides a copy_file_range() fallback.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14795
RN: copy_file_range() may fail with EOPNOTSUPP
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Fri Aug 13 11:45:17 UTC 2021 on sn-devel-184
It seems some systems (like Centos 7) have the SYS_copy_file_range define but
fail the syscall when actually being called. The current configure check is only
compiled, not run so erroneously reports a working SYS_copy_file_range.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14786
RN: Insufficient libreplace check for SYS_copy_file_range check
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 10 19:37:14 UTC 2021 on sn-devel-184
This is based on various patches by Stefan Metzmacher in the patch set for
the Heimdal upgrade.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
CID 1477397
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Apr 27 17:51:36 UTC 2021 on sn-devel-184
Found by covscan
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Sun Apr 25 22:02:20 UTC 2021 on sn-devel-184
This is required in quite a few places, and replace.h has things like
ZERO_STRUCT already, so this is not completely outplaced.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is where it really belongs and we avoid the strange interaction
with source4/heimdal_build/config.h. This a follow up for commit
f31333d40e.
This fixes a build problem if libbsd-dev is not installed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14482
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Björn Jacke <bjacke@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Tue Sep 8 13:59:58 UTC 2020 on sn-devel-184
Commit 810397f89a, and possibly others, broke the build for macOS and
other environments which don't have st_[acm]tim fields on 'struct stat'.
Multiple places in the codebase used the config.h values to determine
how to access the nanosecond or microsecond values of the stat
timestamps, so rather than add more, centralize them all into
lib/util/time.c.
Also allow pvfs_fileinfo.c to read nanosecond-granularity timestamps on
platforms where it didn't before, since its #if branches were not
complete.
Signed-off-by: Matthew DeVore <matvore@google.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Sat Aug 15 08:51:09 UTC 2020 on sn-devel-184
There is no hardcoded IOV_MAX iov limitation on GNU/Hurd. We however do
not want unbound allocation, so define it to a reasonable amount.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Mon Aug 3 09:39:02 UTC 2020 on sn-devel-184
On RHEL7 crypt_r() will set errno. This is a problem because the implementation of crypt_r()
in RHEL8 and elsewhere in libcrypt will return non-NULL but set errno on failure.
The workaround is to use crypt_rn(), provided only by libcrypt, which will return NULL
on failure, and so avoid checking errno in the non-failure case.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14424
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Every time I have to remove an element from within an array I have to
scratch my head about the memmove arguments. Make this easier to use.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Signed-off-by: Peter Eriksson <pen@lysator.liu.se>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Gary Lockyer <<gary@catalyst.net.nz>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Feb 27 21:43:29 UTC 2020 on sn-devel-184
This prevents the following compile error that may happens if "system/filesys.h"
is included before "system/capability.h" on Ubuntu 16.04:
[1802/4407] Compiling source3/lib/system.c
In file included from ../../lib/replace/system/filesys.h:112:0,
from ../../source3/include/vfs.h:29,
from ../../source3/include/smb.h:150,
from ../../source3/include/includes.h:284,
from ../../source3/lib/system.c:23:
/usr/include/x86_64-linux-gnu/sys/xattr.h:32:3: error: expected identifier before numeric constant
XATTR_CREATE = 1, /* set value, fail if attr already exists. */
^
The above error is from compiling a source tree which includes a change that
adds an include "system/filesys.h" to the top of "source3/include/vfs.h".
"source3/lib/system.c" has the following includes:
#include "includes.h"
#include "system/syslog.h"
#include "system/capability.h"
#include "system/passwd.h"
#include "system/filesys.h"
#include "../lib/util/setid.h"
The first include of "includes.h" pulls in "vfs.h" which will pull in
"system/filesys.h" with the mentioned change. "system/filesys.h" pulls in
<attr/xattr.h> which has this define
#define XATTR_CREATE 0x1
Later in "source3/lib/system.c" "system/capability.h" is included which includes
<sys/xattr.h> on Ubuntu 16.04 (not in later versions of glibc). This defines the
XATTR_* values as an enum:
enum {
XATTR_CREATE = 1, /* set value, fail if attr already exists. */
XATTR_REPLACE = 2 /* set value, fail if attr does not exist. */
};
The previous define of XATTR_CREATE as 1 makes this
enum {
1 = 1, /* set value, fail if attr already exists. */
2 = 2 /* set value, fail if attr does not exist. */
};
which is invalid C. The compiler error diagnostic is a bit confusing, as it
prints the original enum from the include file.
See also:
<https://bugs.freedesktop.org/show_bug.cgi?id=78741>
<https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1288091>
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756097>
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Björn Baumbach <bb@samba.org>
Compile error:
[4530/4693] Compiling source3/utils/regedit_list.c
In file included from ../../source3/utils/regedit_list.h:24,
from ../../source3/utils/regedit_list.c:20:
/usr/include/curses.h:611:28: error: conflicting types for ‘attr_get’
611 | extern NCURSES_EXPORT(int) attr_get (attr_t *, NCURSES_PAIRS_T *, void *); /* generated */
| ^~~~~~~~
compilation terminated due to -Wfatal-errors.
Both ncurses and XFS xattr API provide a get_attr() function. As a workaround
avoid including <sys|attr/attributes.h> if <attr|sys/xattr.h> is present.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Thu Dec 12 20:22:51 UTC 2019 on sn-devel-184
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14168
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Wed Oct 23 08:23:13 UTC 2019 on sn-devel-184
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Mon Oct 7 11:48:24 UTC 2019 on sn-devel-184
io_uring is the way to go these days, libaio was never really useful
for Samba
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Oct 4 18:18:41 UTC 2019 on sn-devel-184
On Linux we should avoid linking everything against libpthread. Symbols
used my most application are provided by glibc and code which deals with
threads has to explicitly link against libpthread. This avoids setting
LDFLAGS=-pthread globally.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14140
Signed-off-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Pair-Programmed-With: Isaac Boukris <iboukris@gmail.com>
Reviewed-by: Matthias Dieter Wallnöfer <mdw@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
