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

[Noel Power]

Hi Jeremy
On 04/12/2018 22:55, Jeremy Allison wrote:
> On Tue, Dec 04, 2018 at 10:46:13PM +0000, Noel Power wrote:
>>> We set it on MS-DFS links because we handle them the right way
>>> in smbd on client query.
>> I'll have to look into it but I don't see (like you said) any handling of
>> FILE_OPEN_REPARSE_POINT for the tag IO_REPARSE_TAG_DFS So.. not sure which
>> MS-DFS client queries you mean (but I know practically nothing about DFS)
> Well you can't query IO_REPARSE_TAG_DFS over the network. Once it
> hits an MS-DFS reparse point it returns the required error on
> processing the pathname inside smbd - that's what I mean by
> MS-DFS client queries :-).
>
>> well we could handle FILE_OPEN_REPARSE_POINT at least for mountpoints (only
>> if we have a config option for it set) iirc when opening a reparse point you
>> just need to return the tag associated with the reparse point (in this case
>> IO_REPARSE_TAG_MOUNT_POINT) if and only if the file
> No, it's much nastier than that. Reparse points have a hideously
> complex set of requirements (you can mkdir, turn into a reparse
> point, open it, remove the reparse tag, turn it back into a directory
> etc. etc. etc.). And that's just for directories. The same thing
> happens for files.

But we are not trying to implement or handle any of what you are 
mentioning above,  what I am suggesting here is to provide just a very 
very tight limited READ-ONLY handling of requests to do with 
IO_REPARSE_TAG_MOUNT_POINT type tags, nothing else

If we want to handle open then we only handle it for a directory that 
*is* a mountpoint *and* if the appropriate config is set, otherwise do 
whatever we do currently (nothing or error)

If we wish to allow the reparse point to be read (again only handle 
IO_REPARSE_TAG_MOUNT_POINTs) then its only a case of handling 
FSCTL_GET_REPARSE_POINT requests depending on the file handle (if it 
points to a mountpoint with the appropriate configuration set) otherwise 
reject or error out as appropriate

The data to be provided is quite simple (see 
https://msdn.microsoft.com/en-us/library/cc232007.aspx)

>   Plus if we transit a reparse point that's stored
> on a directory in pathname processing we won't notice.
I'm not sure what you mean here
> Once we start returning FILE_ATTRIBUTE_REPARSE_POINT we've opened
> a hideous can of worms. That's why in my POSIX tree I restrict
> allowing reparse points to zero-length files only, no directories,
> on a POSIX open handle only.
>
> You're planning to gung-ho add FILE_ATTRIBUTE_REPARSE_POINT to
> a directory DOS attribute value. That's my nightmare :-).
I'm not (or at least I don't think I am :-)) the patch adds 
FILE_ATTRIBUTE_REPARSE_POINT only for shares that have the the feature 
enabled and where a particular directory is seen to be a mountpoint.  
Even without supporting FILE_OPEN_REPARSE_POINT I still don't see this 
is much different from what we do for DFS currently
>   It
> has *meaning* to a whole host of Windows apps you're not at
> all prepared to cope with.
>
> What will backup apps start to do then ? It's likely all
> backup apps will now start failing against Samba servers
> once they cross a mount point (hey, why can't I read the
> reparse point data to backup - you told me it was a reparse
> point ?).

hmm, https://msdn.microsoft.com/en-us/library/dd541667.aspx states

"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"

IO_REPARSE_TAG_MOUNT_POINT is one of the "following reparse tags"

>
>> The client could only then get/set/delete the reparse point (but support for
>> these is afaics optional) We probably really don't want a client to be able
>> to create/delete/change an existing mount point on linux, it's possible but
>> would we really want to do it ? For the get reparse point operation we could
>> return some data (but that data probably would be useless to the client) So
>> it's debatably how useful implementing anything other than a stub that
>> returns STATUS_INVALID_DEVICE_REQUEST would be
> If you start returning FILE_ATTRIBUTE_REPARSE_POINT on a directory,
> you're promising a million things we're not prepared to support.
In the general case maybe, I think in this specific case where we only 
attempt to support (or fake) IO_REPARSE_TAG_MOUNT_POINT I don't think so
> Don't do that.

Well I will go with whatever you suggest

Noel