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 aims to minimise usage of the error-prone pattern of searching for
a just-added message element in order to make modifications to it (and
potentially finding the wrong element).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Currently, there are many places where we use ldb_msg_add_empty() to add
an empty element to a message, and then call ldb_msg_add_value() or
similar to add values to that element. However, this performs an
unnecessary search of the message's elements to locate the new element.
Moreover, if an element with the same attribute name already exists
earlier in the message, the values will be added to that element,
instead of to the intended newly added element.
A similar pattern exists where we add values to a message, and then call
ldb_msg_find_element() to locate that message element and sets its flags
to (e.g.) LDB_FLAG_MOD_REPLACE. This also performs an unnecessary
search, and may locate the wrong message element for setting the flags.
To avoid these problems, add functions for appending a value to a
message, so that a particular value can be added to the end of a message
in a single operation.
For ADD requests, it is important that no two message elements share the
same attribute name, otherwise things will break. (Normally,
ldb_msg_normalize() is called before processing the request to help
ensure this.) Thus, we must be careful not to append an attribute to an
ADD message, unless we are sure (e.g. through ldb_msg_find_element())
that an existing element for that attribute is not present.
These functions will be used in the next commit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Using the newly added ldb flag, we can now detect when a message has
been shallow-copied so that its elements share their values with the
original message elements. Then when adding values to the copied
message, we now make a copy of the shared values array first.
This should prevent a use-after-free that occurred in LDB modules when
new values were added to a shallow copy of a message by calling
talloc_realloc() on the original values array, invalidating the 'values'
pointer in the original message element. The original values pointer can
later be used in the database audit logging module which logs database
requests, and potentially cause a crash.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
When making a shallow copy of an ldb message, mark the message elements
of the copy as sharing their values with the message elements in the
original message.
This flag value will be heeded in the next commit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15009
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15095
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from commit 89e0c732b1c45f6498ed0f39add77c2a52afddce)
The first time round we maybe didn't know which files we wanted to log to.
Suppose, for example, we had an smb.conf with
log level = 1 dsdb_group_json_audit:5@/var/log/group_json.log
we wouldn't see anything in "/var/log/group_json.log", while the level
5 dsdb_group_json_audit messages would go into the main log.
Note that the named file would still be opened by winbindd and others
that use the s3 code, but would remain empty as they don't have anything
to say about dsdb_group_json_audit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15076
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 9537ac723cfdc43e718fdd08dc28883e7057a372)
CTDB doesn't want this redirection of stderr to the log file. It
expects to be able to capture stderr of subprocesses and log them with
a header. This redirection stops that from happening.
Unfortunately this has to be a negative option (i.e. "no" in the name)
so that the default of 0/false maintains existing behaviour.
Note that the default behaviour is sub-optimal because it causes raw
data (i.e. debug data without a header) to appear in the log.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15090
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Volker Lendecke <vl@samba.org>
(cherry picked from commit a8091bd0c565a3f14542731e642319dbb68b4786)
This partly reverts commit 620de975f147ac9427b51ea0e1e3eabda443d4b6.
Drop chunk including system/nis.h, drop wscript_build modifications,
use getdomainname() from glibc instead of yp_get_default_domain() from
libnsl.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15087
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from commit b3034f1209a6c45873882415c4291dde7eee76db)
Autobuild-User(v4-16-test): Jule Anger <janger@samba.org>
Autobuild-Date(v4-16-test): Sun Jun 12 10:17:00 UTC 2022 on sn-devel-184
* Fix build problems
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15071
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(v4-16-test): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(v4-16-test): Thu Jun 9 12:14:04 UTC 2022 on sn-devel-184
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15069
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Jun 3 21:53:31 UTC 2022 on sn-devel-184
(cherry picked from commit 3bd753983c8dac33b483affa859984b7e3350d65)
Adds handle based version of gpfswrap_getacl().
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15069
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
(cherry picked from commit d373ff3c01c2c50cd539b78494c0673974a0f046)
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 1b5b4107a5081f15ba215f3025056d509fcfcf2a)
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit ed14513be055cc56eb39785323df2c538a813865)
That will make it easy to see the difference
between two memory buffers.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14956
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit b489b7feda19b3c0f0fe2300f2c76d416776355b)
This simplifies the logic a lot for me.
It also fixes some corner cases regarding whitespaces in the
output, that's why we have to mark a few tests as knownfail,
they will be fixed in the next commit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14956
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 58b09e107cadd7fb8191822d4e7e42657b1ed4c7)
Cleanup to eliminate duplicate code.
The high check is now done against ret.tv_sec,
not 'd', as after calling nt_time_to_unix_timespec_raw()
this is identical to the previous intermediate 'd'
variable.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Jan 11 01:36:51 UTC 2022 on sn-devel-184
Cleanup to eliminate duplicate code.
The low/high checks are now done against ret.tv_sec,
not 'd', as after calling nt_time_to_unix_timespec_raw()
this is identical to the previous intermediate 'd'
variable.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
Not yet used. Does no checks on the converted values.
A later cleanup will allow us to move nt_time_to_unix_timespec()
and nt_time_to_full_timespec() to use common code.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14928
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
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): Wed Jan 5 01:02:38 UTC 2022 on sn-devel-184
Padding this buffer to a multiple of 8 bytes allows the PAC buffer
padding to match Windows.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Running this on sn-devel-184 takes ~14 seconds with the atomic
ops. Without them I did not wait for it to finish. After reducing
NPROCS from 500 to 50 it still ran for more than a minute.
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): Wed Dec 15 01:03:56 UTC 2021 on sn-devel-184
With locking.tdb now based on g_lock.c code, we change locking.tdb a
lot more often. I have a customer case where LDX tortures smbd very
hard with 800+ concurrent connections, which now completely falls over
where 4.12 still worked fine. Some debugging showed a thundering herd
on fcntl locking.tdb index 48 (TDB_SEQNUM_OFS). We still use fcntl for
the seqnum, back when we converted the chainlocks to mutexes we did
not consider it to be a problem. Now it is, but all we need to do with
the SEQNUM is to increment it, so an __atomic_add_fetch() of one is
sufficient.
I've taken a look at the C11 standard atomics, but I could not figure
out how to use them properly, to me they seem more general to be
initialized first etc. All we need is a X86 "lock incl 48(%rax)" to be
emitted, and the gcc __atomic_add_fetch seems to do this.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Fixes build error with samba-4.15.3 and uClibc:
../../source3/printing/samba-bgqd.c: In function ‘main’:
../../source3/printing/samba-bgqd.c:340:21: error: ‘SIGPIPE’ undeclared (first use in this function); did you mean ‘EPIPE’?
../../source3/printing/samba-bgqd.c:384:14: error: ‘SIGTERM’ undeclared (first use in this function)
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Mon Dec 13 16:22:28 UTC 2021 on sn-devel-184
This is the big switch to use samba-dcerpcd for the RPC services in
source3/. It is a pretty big and unordered patch, but I don't see a
good way to split this up into more manageable pieces without
sacrificing bisectability even more. Probably I could cut out a few
small ones, but a major architechtural switch like this will always be
messy.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
If "true" allow smbd and winbindd to spawn samba-dcerpcd
as a named pipe helper. Allows upgrade without any change
to smb.conf. If samba-dcerpcd is run as a daemon this
must be set to "false".
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
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>
The LDB filter processing is where the time is spent in the LDB stack
but the timeout event will not get run while this is ongoing, so we
must confirm we have not yet timed out manually.
RN: Ensure that the LDB request has not timed out during filter processing
as the LDAP server MaxQueryDuration is otherwise not honoured.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14694
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Bug: https://bugzilla.samba.org/show_bug.cgi?id=14908
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Nov 17 18:29:09 UTC 2021 on sn-devel-184
source3 clients need to work in clustered mode, the default
cli_credentials_set_machine_account() only looks at the local
secrets.tdb file
Bug: https://bugzilla.samba.org/show_bug.cgi?id=14908
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@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
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14897
RN: samba process doesn't log to logfile
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Nov 11 14:42:13 UTC 2021 on sn-devel-184
This simplifies the logging API for callers that typically would want to set
logging by just setup_logging() once without bothering that typically
configuration is loaded (via some lpcfg_load*() or lp_load*() varient) which
will only then pick up the configured logfile from smb.conf without actually
applying the new logifle to the logging subsytem.
Therefor our daemons will additionally call reopen_logs() explicitly in their
startup code after config is loaded, eg
setup_logging(getprogname(), DEBUG_FILE);
...
lpcfg_load(lp_ctx, config_file);
...
reopen_logs();
By calling reopen_logs_internal() implicitly from debug_set_logfile() there's no
need to call reopen_logs() explicitly anymore to apply the logfile.
As reopen_logs() will also apply other logging configuration options, we have to
keep the explicit calls in the daemon code. But at least this allows consistent
logging setup wrt to the logfile in the new cmdline library.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14897
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Before I added per-class logfile and we had only one fd for the logfile the code
looked like this:
/* Take over stderr to catch output into logs */
if (state.fd > 0) {
if (dup2(state.fd, 2) == -1) {
/* Close stderr too, if dup2 can't point it -
at the logfile. There really isn't much
that can be done on such a fundamental
failure... */
close_low_fd(2);
}
}
In the current code the equivalent to state.fd is dbgc_config[DBGC_ALL].fd.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14897
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
As we want to reduce use of 'classic domain controller' role but FreeIPA
relies on it internally, add a separate role to mark FreeIPA domain
controller role.
It means that role won't result in ROLE_STANDALONE.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14801
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14556
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Alexander Bokovoy <ab@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
