On 12/27/2024 10:58 AM, Pali Rohár wrote:
Hello, I have redone these tests again. And the results are that
Windows SMB3.1.1 server really filter out this class 64 and does not
allow to use it.
Not surprising. Windows is quite strict about poking holes in the
protocol, which is something Microsoft has a statutory requirement
to adhere to.
But Windows SMB1 server does not filter this class 64 when sent over
SMB PASSTHROUGH (sent as level 0x03e8+64, see [MS-SMB] 2.2.2.3.5), and
normally execute it.
This is very likely a bug and a significant security issue. However,
it will be one of many SMB1 vulnerabilities and Microsoft's "don't use
SMB1" policy will probably prevail over any fix.
I have checked that over first SMB connection I opened the file, then
over second SMB connection I sent that UNLINK command and check that
over second SMB connection the file is not available in the directory
listing anymore, and at the same time over first SMB connection it was
possible to use file handle (of that opened file) for other operations.
So it looks like that at least SMB1 can benefit of this POSIX UNLINK
support. I have also checked that if I used first connection over
SMB3.1.1 then it still worked correctly (opened file handle was usable
and the file was not in directory listing anymore).
"Improving" SMB1 support is a fool's errand and we should not pursue it.
Do you know if SMB3.1.1 has something like [MS-SMB] 2.2.2.3.5
Pass-through Information Level Codes? If yes then it could be
implemented also for SMB3.1.1.
It does not. By design, since SMB2.0.
Tom.
On Monday 14 October 2024 11:49:13 Pali Rohár wrote:
I checked it and seems that both Windows SMB client and Windows SMB
server on Windows Server 2022 filter out this class 64.
Windows SMB client does not send request to server at all and
immediately return error to application which tried to use class 64. And
Windows SMB server returns STATUS_NOT_IMPLEMENTED, which indicates that
server recognized it, but filtered it. Older Windows servers returns
STATUS_INVALID_INFO_CLASS which indicates that they did not understand
class 64 at all.
So seems that against Windows SMB implementation, this class 64 is
unusable for now.
Anyway, can somebody ask in Microsoft if they can allow to use
class 64 (FileDispositionInformationEx) and class 65
(FileRenameInformationEx) in their SMB client and server?
This would really help with Linux/POSIX interop, which Windows already
provided for local filesystems.
Steve, are you able to ask somebody in Microsoft for this?
On Wednesday 09 October 2024 00:03:03 Steve French wrote:
FILE_DISPOSITION_DO_NOT_DELETE 0x00000000 Specifies the system should
not delete a file.
FILE_DISPOSITION_DELETE 0x00000001 Specifies the system should delete a file.
FILE_DISPOSITION_POSIX_SEMANTICS 0x00000002 Specifies the system
should perform a POSIX-style delete.
FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK 0x00000004 Specifies the
system should force an image section check.
FILE_DISPOSITION_ON_CLOSE 0x00000008Specifies if the system sets or
clears the on-close state.
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE 0x00000010 Allows
read-only files to be deleted.
These are interesting flags, but are we certain they are passed
through over SMB3.1.1 by current Windows? It is possible that they
are filtered and thus local only
Have you tried setting them remotely over an SMB3.1.1 mount to Windows server?
On Tue, Oct 8, 2024 at 1:18 PM Pali Rohár <pali@xxxxxxxxxx> wrote:
On Tuesday 08 October 2024 11:40:06 Ralph Boehme wrote:
On 10/6/24 12:31 PM, Pali Rohár wrote:
But starting with Windows 10, version 1709, there is support also
for UNLINK operation, via class 64 (FileDispositionInformationEx)
[1] where is FILE_DISPOSITION_POSIX_SEMANTICS flag [2] which does
UNLINK after CLOSE and let file content usable for all other
processes. Internally Windows NT kernel moves this file on NTFS from
its directory into some hidden are. Which is de-facto same as what
is POSIX unlink. There is also class 65 (FileRenameInformationEx)
which is allows to issue POSIX rename (unlink the target if it
exists).
interesting. Thanks for pointing these out!
What do you think about using & implementing this functionality for
the Linux unlink operation? As the class numbers are already
reserved and documented, I think that it could make sense to use
them also over SMB on POSIX systems.
for SMB3 POSIX this will be the behaviour on POSIX handles so we don't
need an on the wire change. This is part of what will become POSIX-FSA.
Also there is another flag
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE which can be useful for
unlink. It allows to unlink also file which has read-only attribute
set. So no need to do that racy (unset-readonly, set-delete-pending,
set-read-only) compound on files with more file hardlinks.
I think that this is something which SMB3 POSIX extensions can use
and do not have to invent new extensions for the same functionality.
same here (taking note to remember to add this to the POSIX-FSA and
check Samba behaviour).
-slow
So the behavior when the POSIX extension is active would be same as if
every DELETE_ON_CLOSE and every DELETE_PENDING=true requests would set
those new NT flags FILE_DISPOSITION_POSIX_SEMANTICS and
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE?
--
Thanks,
Steve
