Re: SMB2 DELETE vs UNLINK

["Pali Rohár" <pali@kernel.org>]

On Sunday 06 October 2024 23:18:28 Steve French wrote:
> On Sun, Oct 6, 2024 at 5:31 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > Hello,
> >
> > Windows NT systems and SMB2 protocol support only DELETE operation which
> > unlinks file from the directory after the last client/process closes the
> > opened handle.
> >
> > So when file is opened by more client/processes and somebody wants to
> > unlink that file, it stay in the directory until the last client/process
> > stop using it.
> >
> > This DELETE operation can be issued either by CLOSE request on handle
> > opened by DELETE_ON_CLOSE flag, or by SET_INFO request with class 13
> > (FileDispositionInformation) and with set DeletePending flag.
> >
> >
> > 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).
> >
> > 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.
> >
> >
> > 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.
> 
> This is a really good point - but what about mkdir (where we have a
> current bug relating to rmdir of a file after "chmod 0444 dir"

I'm not sure what is doing "chmod 0444 dir". It is setting SMB/NT
read-only attribute?

If yes then FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE sounds like can
be something useful.


But anyway, I think that such bug could be fixed by sending SMB2
compound of following SMB2 commands:
* CREATE with DELETE desired access without DELETE_ON_CLOSE
* SET_INFO with clearing READ_ONLY attribute
* SET_INFO with setting DELETE_PENDING
* SET_INFO with setting READ_ONLY attribute
* CLOSE

CREATE with DELETE_ON_CLOSE fails on object with READ_ONLY attr, so
CREATE(open) has to be called without it. First SET_INFO will try to
remove the protection, to allow second SET_INFO to set DELETE_PENDING
flag. In case setting of it will fail, the third SET_INFO will restore
the protection.

Has SMB2 something like transaction support? NT kernel and its NTFS
subsystem provides transaction FS operations for applications. And I
think that Cygwin is using those FS transactions for race-free
implementation of removing file with read-only attribute.