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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
(SMB_FILE_ALL_INFORMATION - 1000) looks a bit silly if you look at the
definition of SMB_FILE_ALL_INFORMATION...
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The raw SMB2-INVALID-PIPENAME test passes against Windows 2022,
as it just returns NT_STATUS_OBJECT_NAME_NOT_FOUND.
Add the knownfail.
BUG:https://bugzilla.samba.org/show_bug.cgi?id=15422
Signed-off-by: Jeremy Allison <jra@samba.org>
Looks much larger than it is, there's a lot of callers too feed NULL to.
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): Mon Sep 25 19:59:17 UTC 2023 on atb-devel-224
Shows the server crashes if we open a named pipe, do an async read
and then disconnect.
Adds knownfail:
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15423
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This makes it clearer what to pass into the create_flags argument to
cli_smb2_create_fnum(). There was already confusion in
source3/torture/test_smb2.c: It passed in
SMB2_OPLOCK_LEVEL_NONE (which was okay because it #defines to 0), but
it should have been a straight 0, for example
SMB2_OPLOCK_LEVEL_EXCLUSIVE would have been wrong.
This way adding other flags (.nofollow comes to mind) will be much
easier to handle.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
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>
Looks larger than it is, this just adds a parameter and while there
adapts long lines to README.Coding
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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
There is only one difference between Windows 2022 and Windows 2008.
Opening an empty ("") DFS path succeeds in opening the share
root on Windows 2008 but fails with NT_STATUS_INVALID_PARAMETER
on Windows 2022. Allow the test to cope with both.
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>
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
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>
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>
It shows this isn't done correctly for streams_xattr.
A common config is:
vfs_objects = streams_xattr acl_xattr
to store both streams and Windows ACLs in xattrs.
Unfortunately getting and setting ACLs using handles
opened on stream files isn't being done correctly
in Samba.
This test passes against Windows 10.
This adds tests that prove this doesn't work. Next
patch will add the fix and remove the knownfail.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Shows bits needed to set/get a SACL. We need a script within Samba to run this
as it depends on a user with SeSecurityPrivilege to work.
Test does the following:
1). Create a test file.
2). Open with SEC_FLAG_SYSTEM_SECURITY *only*. ACCESS_DENIED.
NB. SMB2-only behavior. SMB1 allows this as tested in SMB1-SYSTEM-SECURITY.
3). Open with SEC_FLAG_SYSTEM_SECURITY|FILE_WRITE_ATTRIBUTES.
4). Write SACL. Should fail with ACCESS_DENIED (seems to need WRITE_DAC).
5). Close (3).
6). Open with SEC_FLAG_SYSTEM_SECURITY|SEC_STD_WRITE_DAC.
7). Write SACL. Success.
8). Close (4).
9). Open with SEC_FLAG_SYSTEM_SECURITY|READ_ATTRIBUTES.
10). Read SACL. Success.
11). Read DACL. Should fail with ACCESS_DENIED (no READ_CONTROL).
12). Close (9).
13 - and on error). Delete test file.
Passes against Windows 10.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
[MS-FSA] 2.1.5.1 Server Requests an Open of a File.
Checks how to behave on both files and directories.
Tested against Windows 10 server - passes. Currently smbd fails this.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Tests against a directory handle on the root of a share,
and a directory handle on a sub-directory in a share.
Check SEC_DIR_ADD_FILE and SEC_DIR_ADD_SUBDIR separately,
either allows flush to succeed.
Passes against Windows.
Regression test for:
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13428
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri May 18 02:38:50 CEST 2018 on sn-devel-144
There're no callers which try to pass a raw lm_response directly anymore.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Fri Dec 9 13:09:37 CET 2016 on sn-devel-144
There're no callers which tried to pass raw {lm,nt}_response any more.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Fri Sep 19 11:40:15 CEST 2014 on sn-devel-104
