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

[Daniel Fussell]

On 1/30/19 12:53 AM, Noel Power via samba-technical wrote:
> H James,
>
> On 28/01/2019 23:40, James Ashdown wrote:
>> Noel,
>>
>> 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 ? Sorry for the maybe obvious
> questions, haven't looked at this in a while.
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.

>
>> Let me know what you think.
> 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?

Grazie,
Daniel Fussell