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 failed to start, emitting the following error:
Unknown torture operation 'clustered.smb2.deny.deny2'
To fix this, remove the 'clustered.' prefix from the test name.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Trying to run any of these tests without having built ctdb results in a
failure, as the environment cannot be started.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
There is no need to run it against this environment and saves resources.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Remove knownfail on SMB1-DFS-SEARCH-PATHS, as we now
pass it with the new SMB1 remove DFS paths before pathname processing
changes.
Note, we still fail:
smb1.SMB1-DFS-PATHS.smbtorture\(fileserver_smb1\)
smb1.SMB1-DFS-OPERATIONS.smbtorture\(fileserver_smb1\)
even with the new SMB1 remove DFS paths before pathname
processing as those tests test *very* specific Windows behaviors. We now
pass many more of the individual internal tests, but
in order to pass them all completely I need to add
specific --with-sambaserver checks to avoid some
of the Windows DFS SMB1 insanity (error messages).
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): Fri Mar 31 06:07:01 UTC 2023 on atb-devel-224
smbclient crashes when smbd has "smb2 max read = 0"
in the [global] section of smb.conf.
We should fail the protocol negotiation with
NT_STATUS_INVALID_NETWORK_RESPONSE in this case.
Adds knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15306
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Shows we are leaking an fsp/fd if we request a non-existent stream on a file.
This then causes rename of a directory containing the file to be denied, as
it thinks we have an existing open file below it.
Add knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15314
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15287
Signed-off-by: Pavel Filipenský <pfilipensky@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Thu Jan 26 15:07:57 UTC 2023 on atb-devel-224
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Thu Jan 26 13:13:50 UTC 2023 on atb-devel-224
Shows that we fail to cope with MacOSX clients that send a
(or more than one) leading '\\' character for an SMB2 DFS pathname.
I missed this in earlier tests as Windows, Linux, and
libsmbclient clients do NOT send a leading backslash
for SMB2 DFS paths. Only MacOSX (sigh:-).
Passes against Windows. Adds a knownfail for smbd.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15277
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
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): Wed Dec 21 20:05:59 UTC 2022 on sn-devel-184
It doesn't hurt the fsync compound async tests, and we need this for
the next commits to ensure smb2_read/smb2_write compound tests take
longer than 500ms so can be sure the last read/write in the compound
will go async.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This still all fails, but if you run them against Windows they work.
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): Tue Nov 22 19:25:34 UTC 2022 on sn-devel-184
This still all fails, but if you run them against Windows they work.
How to run:
PYTHONPATH=bin/python \
LOCAL_PATH=/tmp \
SMB1_SHARE=share \
SMB2_SHARE=share \
SHARENAME=share \
SERVER_IP=<server-ip> \
DOMAIN=<your-domain> \
USERNAME=Administrator \
PASSWORD=<your-password> \
SMB_CONF_PATH=/usr/local/samba/etc/smb.conf \
SERVERCONFFILE="$SMB_CONF_PATH" \
python3 -m samba.subunit.run samba.tests.reparsepoints
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Shows we fail sending an SMB2_OP_FLUSH + SMB2_OP_CLOSE
compound. Internally the flush goes async and
we free the req, then we process the close.
When the flush completes it tries to access
already freed data.
Found using the Apple MacOSX client at SNIA SDC 2022.
Add knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15172
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Thanks to Metze for the hint that all file servers already listen on 2
addressess -- V4 and V6 :-)
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Thu Nov 10 08:23:14 UTC 2022 on sn-devel-184
Uses non-DFS names and DFS-names against a DFS share, shows that Windows
looks correctly at the DFS flag when SMB2 requests are
made on a DFS share. Passes against Windows 2022.
Mark as knownfail for smbd.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Wed Sep 28 19:34:29 UTC 2022 on sn-devel-184
Only tests SMB1unlink for now, but I will add other operations
later.
smbtorture3 test is: SMB1-DFS-OPERATIONS.
Passes fully against Windows. Adds knownfail for smbd.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
This one is tricky. It sends SMB2 DFS pathnames to a non-DFS
share, and sets the SMB2 flag FLAGS2_DFS_PATHNAMES in the SMB2
packet.
Windows will have non of it and (correctly) treats the pathnames
as local paths (they're going to a non-DFS share). Samba fails.
This proves the server looks as the share DFS capability to
override the flag in the SMB2 packet.
Passes against Windows. Added knownfail for Samba.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
This demonstrates that a client-guid connected to ctdb node 0
caused a connection with the same client-guid to be rejected by
ctdb node 1. Node 1 rejects the SMB2 Negotiate with
NT_STATUS_NOT_SUPPORTED, because passing the multi-channel connection
to a different node is not supported.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15159
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
smbtorture3 test is: SMB1-DFS-PATHS
Tests open, and then all 4 methods of renaming/hardlinking
files:
1). SMBmv
2). SMBtrans2 SETPATHINFO
3). SMBtrans2 SETFILEINFO
4). SMBntrename
Also added a test for SMB1findfirst.
smbtorture3 test is: SMB1-DFS-SEARCH-PATHS.
What this shows is that Windows strips off the
SMB1findfirst mask *before* calling the DFS path
parser (smbd currently does not).
Added so we know how to fix the server code to match Windows
behavior in parsing DFS paths in different calls going forward.
Passes fully against Windows. Adds knownfails for smbd.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <noel.power@suse.com>
Make sure we do and don't announce posix depending on "smb3 unix
extensions" parameter
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Passes fully against Windows.
This shows that DFS paths on Windows on SMB2 must
be of the form:
SERVER\SHARE\PATH
but the actual contents of the strings SERVER and
SHARE don't need to match the given server or share.
The algorithm the Windows server uses is the following:
Look for a '\\' character, and assign anything before
that to the SERVER component. The characters in this
component are not checked for validity.
Look for a second '\\' character and assign anything
between the first and second '\\' characters to the
SHARE component. The characters in the share component
are checked for validity, but only ':' is flagged as
an illegal sharename character despite what:
[MS-FSCC] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/dc9978d7-6299-4c5a-a22d-a039cdc716ea
says.
Anything after the second '\\' character is assigned
to the PATH component and becomes the share-relative
path.
If there aren't two '\\' characters it removes
everything and ends up with the empty string as
the share relative path.
To give some examples, the following pathnames all map
to the directory at the root of the DFS share:
SERVER\SHARE
SERVER
""
ANY\NAME
ANY
::::\NAME
the name:
SERVER\:
is illegal (sharename contains ':') and the name:
ANY\NAME\file
maps to a share-relative pathname of "file",
despite "ANY" not being the server name, and
"NAME" not being the DFS share name we are
connected to.
Adds a knownfail for smbd as our current code
in parse_dfs_path() is completely incorrect
here and tries to map "incorrect" DFS names
into local paths. I will work on fixing this
later, but we should be able to remove parse_dfs_path()
entirely and move the DFS pathname logic before
the call to filename_convert_dirfsp() in the
same way Volker suggested and was able to achieve
for extract_snapshot_token() and the @GMT pathname
processing.
Also proves the "target" paths for SMB2_SETINFO
rename and hardlink must *not* be DFS-paths.
Next I will work on a torture tester for SMB1
DFS paths.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reivewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 30 17:10:33 UTC 2022 on sn-devel-184
Shows we currently don't look at smb.conf veto files parameter
when opening a file or directory. Checks multi-component paths.
Also checks veto files that might be hidden behind a mangled
name.
Add knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15143
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
When using vfs_streams_xattr, for a pathref handle of a stream the system fd
will be a fake fd created by pipe() in vfs_fake_fd().
For the following callchain we wrongly pass a stream fsp to
SMB_VFS_FGET_NT_ACL():
SMB_VFS_CREATE_FILE(..., "file:stream", ...)
=> open_file():
if (open_fd):
-> taking the else branch:
-> smbd_check_access_rights_fsp(stream_fsp)
-> SMB_VFS_FGET_NT_ACL(stream_fsp)
This is obviously wrong and can lead to strange permission errors when using
vfs_acl_xattr:
in vfs_acl_xattr we will try to read the stored ACL by calling
fgetxattr(fake-fd) which of course faild with EBADF. Now unfortunately the
vfs_acl_xattr code ignores the specific error and handles this as if there was
no ACL stored and subsequently runs the code to synthesize a default ACL
according to the setting of "acl:default acl style".
As the correct access check for streams has already been carried out by calling
check_base_file_access() from create_file_unixpath(), the above problem is not
a security issue: it can only lead to "decreased" permissions resulting in
unexpected ACCESS_DENIED errors.
The fix is obviously going to be calling
smbd_check_access_rights_fsp(stream_fsp->base_fsp).
This test verifies that deleting a file works when the stored NT ACL grants
DELETE_FILE while the basic POSIX permissions (used in the acl_xattr fallback
code) do not.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15126
MR: https://gitlab.com/samba-team/samba/-/merge_requests/2643
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
This way it is easier to select them with 'make test'.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Pavel Filipenský <pfilipensky@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14765
RN: add new smb.conf parameter "volume serial number" to allow overriding
the generated default value
Signed-off-by: Christian Ambach <ambi@samba.org>
Reviewed=by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Jun 6 17:42:37 UTC 2022 on sn-devel-184
This ensures we detect the runtime system and release, not the ones
when Samba was build. It's necessary to detect the correct kernel
version we're running on because for kernels before 5.3.1 O_PATH opens
unnecessarily broke kernel oplocks, which breaks our tests. And in
gitlab it can happen that we build on kernels after 5.3.1 and later
run on older kernels. In this situation we can't run kernel oplock
tests.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15041
Signed-off-by: Pavel Filipenský <pfilipen@redhat.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
This bases File-Ids on the inode numbers again. The whole stuff was
added because at that time Apple clients
1. would be upset by inode number reusage and
2. had a client side bug in their fallback implemetentation that
assigns File-Ids on the client side in case the server provides
File-Ids of 0.
After discussion with folks at Apple it should be safe these days to
rely on the Mac to generate its own File-Ids and let Samba return 0
File-Ids.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We don't need seperate test suites here, all tests are related to
File-Ids.
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
