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

[Jeremy Allison]

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. Plus if we transit a reparse point that's stored
on a directory in pathname processing we won't notice.

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 :-). 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 ?).

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

Don't do that.

Jeremy.