[Patch] dosmode: Compare block devices to detect reparse points

[James Ashdown]

On 1/30/19 16:11, Daniel Fussell via samba-technical wrote:

> On 1/30/19 12:53 AM, Noel Power via samba-technical wrote:
>> On 28/01/2019 23:40, James Ashdown wrote:
>>> I'm attaching a revision of the patch that makes use of your idea to
>>> re-use the parent directory stat on a FIND operation. Turns out that
>>> it works beautifully, no additional stat calls needed there.
>>>
>>> However, I encountered a snag when I implemented just that. It seems
>>> that when a Windows 10 File Explorer client opens a
>>> reparsepoint-marked directory sends a CREATE request targeting that
>>> directory,
>> how do you trigger the CREATE request?
> It is essentially open existing file/directory, or create and open
> non-existing file/directory.
>>> the client overwrites its reparsepoint state for that directory. In
>>> effect, if you enter a directory and then quickly leave and re-enter
>>> it, write and copy operations "forget" that there was ever a
>>> reparsepoint file attribute set.
>> so you mean if you click into a dir mountpoint and quickly leave (say
>> clicking the parent) and then click back again ? Then try a copy and it
>> will revert back to (in my example from earlier in the thread) using the
>> quota associated with the parent dir share ?
> Exactly
>>> To fix that, I mimicked the CREATE flag that Windows File Server
>>> returns. This is not in the file attributes bit field, but has the
>>> effect of preserving the set FILE_ATTRIBUTE_REPARSEPOINT returned in
>>> the FIND response. Detecting the mountpoint here requires an
>>> additional stat for each CREATE that targets a directory.
>> Do you have before and after network traces (would help to point out the
>> relevant packets in each for comparison) At least for me I haven't
>> looked at this in a while and could do with a big fat finger pointing
>> things out :-)
> Yes, we've been using wireshark to compare our patch's packets against
> an MS server with a similar directory structure so we can better match
> the behavior.  We may not have saved the packet traces, but we can
> certainly generate them again if you want to see them.
>
> We haven't spent a lot of time looking for other operations that might
> need to return the same flags.  CLOSE
> is the obvious additional candidate, but in our limited testing, we
> never saw the file attributes go across the wire.  That doesn't mean it
> would never happen though, so we might have to check that out.
>> Also did you find any documentation around the flag you are
>> setting ? I seem to recall finding precious little about the associated
>> flags and when/how to use them when I last looked.
>  From MS-SMB2 (and Jeremy, feel free to jump in and correct me if I'm
> wrong here):
>
> The SMB2_CREATE_FLAG_REPARSEPOINT flag is documented at
> https://msdn.microsoft.com/en-us/library/cc246512.aspx (and now that I
> re-read the "Flags" definition, we may have to modify the patch such
> that this flag is only set if SMB3.x was negotiated.)
>
> The FILE_ATTRIBUTE_REPARSE_POINT flag is documented at
> https://msdn.microsoft.com/en-us/library/cc232110.aspx
>
> Furthermore, MS-FSCC section 2.1.2.1 paragraph 3, says "The following
> reparse tags, with the exception of IO_REPARSE_TAG_SYMLINK, are
> processed on the server and are not processed by a client after
> transmission over the wire.  Clients SHOULD treat associated reparse
> data as opaque data."  I've probably quoted this before, and I don't
> mean to be a broken record, but I paid an awful price finding it again
> and again in all the wrong places.
>
>  From those three references, I gather that the flags clue the client
> into existence of a reparse point.  While it is true that a client could
> potentially issue an FSCTL or IOCTL with the intent of setting or
> reading a reparse point, the FSCTL and IOCTL's are implementation
> specific.  So supporting some controls and not others seems reasonable.
>
> Furthermore, regarding Jeremy's aforementioned
> FSCTL_REPARSE_POINT-implicit-promise-is-can-of-worms concern, MS-SMB2
> 3.3.5.15 paragraph 12 says "The server SHOULD fail the request with
> STATUS_NOT_SUPPORTED when an FSCTL is not allowed on the server, and
> SHOULD fail the request with STATUS_INVALID_DEVICE_REQUEST when the
> FSCTL is allowed, but is not supported on the file system on which the
> file or directory handle specified by the FSCTL exists, as specified in
> [MS-FSCC] section 2.2."
>
> As I understand it, fsutil requires admin privileges in the first place,
> so I think it perfectly reasonable to reject a FSCTL_SET_REPARSE_POINT
> call with STATUS_NOT_SUPPORTED because it doesn't mean anything in this
> context.  And yeah, FSCTL_GET_REPARSE_POINT might be callable by a
> process with Backup privileges, so maybe STATUS_NOT_SUPPORTED isn't the
> best return for that, or maybe it is.  Maybe there is another error we
> can return like STATUS_CONTINUE or STATUS_MOVE_ALONG_NOTHING_TO_SEE_HERE.
>
> But besides Backup and Admin privileged processes, it looks to me like
> everyone else would be denied reading or writing a reparse tag and the
> same with any application they might be running.  So restating the prior
> question, would it be reasonable to make reparse mountpoint
> detection/flagging a config option, and  revisit changing the default at
> some future time?
>
What remains to be done for this patch to be considered for upstream integration?