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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
We currently allow setting the delete on close bit for
a directory containing only explicitly hidden/vetoed files
in the case where "delete veto files = yes" *and*
"delete veto files = no". For the "delete veto files = no"
case we should be denying setting the delete on close bit
when the client tries to set it (that's the only time Windows
looks at the bit and returns an error to the user). We
already do the in the dangling symlink case, we just
missed it in the !is_visible_fsp() case.
Mark SMB2-DEL-ON-CLOSE-NONWRITE-DELETE-NO as knownfail
for now.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15023
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Noel Power <npower@samba.org>
Running these tests twice is a waste (sorry, thas was my choice when
merging s3 and s4 to just run all the tests against the AD DC) and
more importantly means that tests are run in "samba3" mode against
the AD DC, making it difficult to change the tests to expect a different
behaivour against the AD DC compared to the NT4 DC.
To assure that we have not lost tests, I ran:
grep command st/subunit | grep ad_dc| cut -f 2 -d\" | cut -f 2- -d. | sort | uniq -c
The two blocks (for rpc.lsa and rpc.lsa.*) are because the rpc.lsa.*
subtests were not previously run under ncacn_ip_tcp: and this is the
minimal change.
The output is:
--- /tmp/3 2022-02-12 14:01:50.435761067 +1300
+++ /tmp/now 2022-02-12 14:01:37.427595351 +1300
@@ -13,9 +13,8 @@
2 rpc.lsa-getuser on ncalrpc with validate.
2 rpc.lsa-getuser with bigendian.
2 rpc.lsa-getuser with seal,padcheck.
2 rpc.lsa-getuser with validate.
- 2 rpc.lsa.lookupnames.
2 rpc.lsa.lookupnames with .
2 rpc.lsa.lookupnames with bigendian.
2 rpc.lsa.lookupnames with validate.
2 rpc.lsalookup on ncacn_ip_tcp with bigendian.
@@ -26,9 +25,8 @@
2 rpc.lsalookup on ncacn_np with validate.
2 rpc.lsalookup on ncalrpc with bigendian.
2 rpc.lsalookup on ncalrpc with seal,padcheck.
2 rpc.lsalookup on ncalrpc with validate.
- 2 rpc.lsa.lookupsids.
2 rpc.lsa.lookupsids with .
2 rpc.lsa.lookupsids with bigendian.
2 rpc.lsa.lookupsids with validate.
2 rpc.lsalookup with bigendian.
@@ -42,15 +40,11 @@
2 rpc.lsa on ncacn_np with validate.
2 rpc.lsa on ncalrpc with bigendian.
2 rpc.lsa on ncalrpc with seal,padcheck.
2 rpc.lsa on ncalrpc with validate.
- 2 rpc.lsa over ncacn_ip_tcp .
- 2 rpc.lsa over ncacn_np .
- 2 rpc.lsa.privileges.
2 rpc.lsa.privileges with .
2 rpc.lsa.privileges with bigendian.
2 rpc.lsa.privileges with validate.
- 2 rpc.lsa.secrets.
2 rpc.lsa.secrets on ncacn_np with with -k no --option=clientusespnego=no.
2 rpc.lsa.secrets on ncacn_np with with -k no --option=clientusespnego=no --option=clientntlmv2auth=yes.
2 rpc.lsa.secrets on ncacn_np with with -k no --option=clientusespnego=yes.
2 rpc.lsa.secrets on ncacn_np with with -k no --option=clientusespnego=yes --option=clientntlmv2auth=yes.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Running these tests twice is a waste (sorry, thas was my choice when
merging s3 and s4 to just run all the tests against the AD DC) and
more importantly means that tests are run in "samba3" mode against
the AD DC, making it difficult to change the tests to expect a different
behaivour against the AD DC compared to the NT4 DC.
To assure that we have not lost tests, I ran:
grep command st/subunit | grep ad_dc| cut -f 2 -d\" | cut -f 2- -d. | sort | uniq -c
The output is:
--- /tmp/2 2022-02-11 21:00:54.033610748 +1300
+++ /tmp/now 2022-02-11 21:01:13.849823721 +1300
@@ -1,32 +1,21 @@
- 2 rpc.samr.
- 2 rpc.samr.handletype.
2 rpc.samr.handletype with .
2 rpc.samr.handletype with bigendian.
2 rpc.samr.handletype with validate.
- 2 rpc.samr.large-dc.
2 rpc.samr.large-dc on ncacn_np with .
- 2 rpc.samr.machine.auth.
2 rpc.samr.machine.auth with .
2 rpc.samr.machine.auth with bigendian.
2 rpc.samr.machine.auth with validate.
2 rpc.samr on ncacn_np with .
- 2 rpc.samr.passwords.
- 2 rpc.samr.passwords.badpwdcount.
2 rpc.samr.passwords.badpwdcount on ncacn_np with .
2 rpc.samr.passwords.lockout on ncacn_np with .
2 rpc.samr.passwords on ncacn_np with .
- 2 rpc.samr.passwords.pwdlastset.
2 rpc.samr.passwords.pwdlastset on ncacn_np with .
2 rpc.samr.passwords.validate on ncacn_ip_tcp with bigendian.
2 rpc.samr.passwords.validate on ncacn_ip_tcp with seal,padcheck.
2 rpc.samr.passwords.validate on ncacn_ip_tcp with validate.
- 2 rpc.samr.passwords.validate over ncacn_ip_tcp .
- 2 rpc.samr.priv.
2 rpc.samr.priv with .
2 rpc.samr.priv with bigendian.
2 rpc.samr.priv with validate.
- 2 rpc.samr.users.
2 rpc.samr.users on ncacn_np with .
- 2 rpc.samr.users.privileges.
2 rpc.samr.users.privileges on ncacn_np with .
4 tests.dcerpc.samr_change_password.
It is clear that the tests are all still being run at least once against the AD DC.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Pavel Filipenský <pfilipen@redhat.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Verifies async-dosmode sync fallback works with shadow_copy2 which returns
ENOSYS for SMB_VFS_GET_DOS_ATTRIBUTES_SEND().
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14957
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The whole "smbd:force sync [user|root] [path|chdir] safe threadpool" stuff was
removed long ago by 29dd6f3e59.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14957
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Bug: https://bugzilla.samba.org/show_bug.cgi?id=14971
Signed-off-by: Pavel Filipenský <pfilipen@redhat.com>
Pair-Programmed-With: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Run vfstest with this vfstest.cmd under valgrind and you'll see what
happens. Exact explanation a few patches further down...
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The cleanup using dump_data_block16() fixed the space handling.
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>
smb2.fileid_unique.fileid_unique
smb2.fileid_unique.fileid_unique-dir
Create 100 files or directories as fast as we can
against a "normal" share, then read info on them
and ensure (a) top bit is set (generated from itime)
and (b) uniqueness across all generated objects
(checks poor timestamp resolution doesn't create
duplicate fileids).
This shows that even on ext4, this is enough to
cause duplicate fileids to be returned.
Add knownfail.d/fileid-unique
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>
This is pre WindowXP SMB1 functionality, and we
need to remove this from the server in order to
move towards SMB2-only, so the test must go.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Exposes an existing problem where "ret" is overwritten
in the directory scan.
Add knownfail.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14892
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
