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

[James Ashdown]

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, 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.

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.

Let me know what you think.

James

On 12/5/18 04:57, Noel Power wrote:
> 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)
>> 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
>
> Noel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Detect-volume-mountpoint-reparsepoints-for-FIND-and-.patch
Type: text/x-patch
Size: 9601 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190128/8d4a227a/0001-Detect-volume-mountpoint-reparsepoints-for-FIND-and-.bin>