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 test case checks what happens when we have an intermediate request
failure and how it impacts rest of the chain.
Signed-off-by: Anubhav Rakshit <anubhav.rakshit@gmail.com>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We already pass samba3.smb2.compound.related5, but mark related4 as knownfail.
Signed-off-by: Anubhav Rakshit <anubhav.rakshit@gmail.com>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Apr 7 17:32:07 UTC 2021 on sn-devel-184
The last user of SMB_VFS_REMOVEXATTR() is gone, I can now
remove the internal VFS functions implementing it.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
We know this is safe as SMB_VFS_SYS_ACL_DELETE_DEF_FILE() is only
ever called on an fsp->fsp_name.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Note that now we're doing this by handle
not by pathname we must do it on the base_fsp,
as we have to remove the actual xattr on the base file.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Change SMB_VFS_NEXT_REMOVEXATTR() -> SMB_VFS_NEXT_FREMOVEXATTR().
It doesn't need to do STAT calls, it's always called
with an fsp->fsp_name smb_filename. This will change
later to a handle-based call.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Ensure it only uses an io fd for a handle based call.
Otherwise fall back to pathname based. This is the same as the
fallback used in vfs_default.c
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Ensure it only uses an io fd for a handle based call.
Otherwise fall back to pathname based. This is the same as the
fallback used in vfs_default.c
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Changes use of SMB_VFS_REMOVEXATTR() -> SMB_VFS_FREMOVEXATTR().
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This means adding a synthetic_pathref() call into the
nfs4acl_xattr version of SMB_VFS_GET_NT_ACL_AT() which
is the pathname-based ACL fetch call.
One place where this (smb_fname->fsp == NULL)
can happen is from open when checking parent
directory ACL - check_parent_access() currently
isn't always passed a smb_fname with a valid
fsp and check_parent_access() currently doesn't
open a pathref smb_fname->fsp itself (eventually
it should be passed in a pathref from the caller).
There are also a few other places inside smbd
that call smbd_check_access_rights() also without
a pathref fsp.
This check should be moved into the
callers inside smbd to ensure that smb_fname->fsp
is always valid here, and in a later patchset (not
part of this set) I will do just that.
Ultimately it may be possible to remove
pathname based SMB_VFS_GET_NT_ACL_AT(), this
requires further investigation.
But until then, we need this change.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
We know that the parent name must
exist, and the name has been canonicalized
even if this was a POSIX pathname.
Ensure that we follow symlinks for
the parent. See the torture test
POSIX-SYMLINK-PARENT for details.
Remove knownfail entry.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Wed Apr 7 15:39:45 UTC 2021 on sn-devel-184
This creates a directory, then a symlink to a directory,
and then checks we can POSIX create and delete file, directory,
symlink and hardlink filesystem objects under the symlink
parent directory.
Mark as knownfail until next commit.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Apr 7 10:24:17 UTC 2021 on sn-devel-184
Move include of system/network.h to avoid a build error:
In file included from ../../lib/replace/system/network.h:35,
from ../../librpc/rpc/dcesrv_core.c:2658:
usr/include/unistd.h: At top level:
usr/include/unistd.h:675:16: error: conflicting types for ‘geteuid’
675 | extern __uid_t geteuid (void) __THROW;
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Right now a new association group is created for each connection
assigning the legacy 0x53F0 id, but it is not stored anywhere. When a
second client request to join an association group by its id it is not
found and a new one is created with the same ID.
In practise, it means the association groups are not working even in the
same server process.
This commit stores the created association group in the idtree, but to
make use of it assigns a random id instead of the historical 0x53F0.
The test assoc_group_ok2 was wrongly passing before this change because
the same id 0x53F0 was assigned to all association groups.
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
If the client requests to join to an association group in the bind operation
try to find it and do not create a new one.
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Add a test to check if a RPC handle can be used from a different connection
than the one where it was created, when the same association group is
requested in the bind operation of the second connection.
The association group handling is one of the differences between the S3
and S4 RPC server implementations provided by the implementation
callbacks after the merge.
Association groups work fine in the S4 implementation as the RPC server
runs in one process, except for the 'smbd' embedded services provided
by the S3 implementation like winreg (see lp_enforce_ad_dc_settings()).
In the S3 implementation, association groups should work in the same
process, but the merge introduced a bug where a new association group is
always created even when it already exists in the same process.
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14621
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14621
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
While crypt_rn() always returns a null pointer in the event of
failure, crypt() and crypt_r() may instead return a string starting
with the character '*'. This commit adds a check to detect failure in
this case.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14621
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The current length of 128-255 UTF-16 characters currently causes
generation of crypt() passwords to typically fail. This commit
decreases the length to 120 UTF-16 characters, which is the same as
that used by Windows.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14621
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Since the length of the krbtgt password after conversion to UTF-8 form is
typically greater than the maximum accepted by crypt(), the call usually
fails. This commit disables generation of crypt() passwords for this specific
account, as it's not necessary.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14621
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14621
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
As seen in CVE-2021-20277, ldb_handler_fold() has been making mistakes
when collapsing spaces down to a single space.
This patch fixes the way it handles internal spaces (CVE-2021-20277
was about leading spaces), and involves a rewrite of the parsing loop.
The bug has a detailed description of the problem.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14656
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Apr 7 03:16:39 UTC 2021 on sn-devel-184
We run one character over in comparing all the bytes in two ldb_vals.
In almost all circumstances both ldb_vals would have an allocated '\0'
in the overrun position, but it is best not to rely on that.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If -Wl,--as-needed is added to EXTRA_LDFLAGS (via ADD_LDFLAGS, as per
commit 996560191a) then on some
platforms (at least CentOS 8 and Fedora 33), any indirect/recursive
dependencies (i.e. private libraries) are added to both the
binary (reqid_test in the CTDB case) and to samba-util.so. However,
only samba-util.so has rpath set to find private libraries.
When ld.so tries to resolve these dependencies for the binary it
fails. This may be a bug on those platforms, but it occurs reliably
and our users will also hit the bug. For binaries that have other
private library dependencies (e.g. bundled talloc) rpath will contain
the private library directory so the duplicate private library
dependencies are then found... that is, when it works, it works by
accident!
For some reason (deep in waf or wafsamba) if -Wl,--as-needed is added to
LINKFLAGS (as is done in conf.add_as_needed()) then it works: the direct
dependencies are only added to samba-util.so and the same depenencies
(indirect dependencies for binaries) are not added incorrectly to the
binaries.
So, without changing 1/2 of waf/wafsamba the simplest fix is to revert
to adding -Wl,--as-needed to LINKFLAGS, which was the case before
commit 996560191a.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14288
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Bjoern Jacke <bj@sernet.de>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
