s3: torture: Add a comprehensive SMB2 DFS path torture tester.
authorJeremy Allison <jra@samba.org>
Mon, 29 Aug 2022 21:37:35 +0000 (14:37 -0700)
committerJeremy Allison <jra@samba.org>
Tue, 30 Aug 2022 17:10:33 +0000 (17:10 +0000)
commite492986661039f2e8a1000529e21dc5b2061d5f6
tree3a75ead71b519be7e373bef810a1fb1533508edd
parent772319412df7804236e1cc06056474469bcdcb66
s3: torture: Add a comprehensive SMB2 DFS path torture tester.

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
selftest/knownfail.d/dfs_paths [new file with mode: 0644]
selftest/target/Samba3.pm
source3/selftest/tests.py
source3/torture/proto.h
source3/torture/test_smb2.c
source3/torture/torture.c