[PATCH] Allow reparse points to be created/read/removed over SMB2 from smbclient.

[Daniel Fussell]

On 12/01/2017 10:11 AM, Jeremy Allison via samba-technical wrote:
> On Fri, Dec 01, 2017 at 09:34:10AM -0700, Daniel Fussell via samba-technical wrote:
>> On 11/29/2017 04:22 PM, Jeremy Allison via samba-technical wrote:
>>> Latest part of my quest to get a working test environment
>>> for reparse points so I can implement them in smbd.
>> Jacob Holtom and I have been working on the smbd symlink reparse point
>> code as well, changing it to properly return the symlink error/reparse
>> responses instead of just adding the reparse tag.
>>
>> Our target environment does not support extended attributes.  We've been
>> talking about using the UNIX symlink target as the link-target when the
>> follow symlinks option is enabled.  Does anyone have any objections?
> Yes, I don't want smbd creating UNIX symlinks anymore.
>
> This has been and continues to be a big security hole.
>
> I only want reparse points stored in EA's.
>
> Jeremy.
>

I'm assuming the big security hole is largely TOCTTOU races and/or wide
links.  If there's more to it, please enlighten me.

If I understand correctly, you want reparse point flags stored in the EA
only, so the server cannot follow it, period.  If the target isn't in
the share, resolvable by the client, you can't get there from here. 
It's also easier to code, no doubt.  Am I understanding correctly?

My problem with the EA-only approach is it breaks expected behavior on
multi-protocol filers (and the local filesystem).  If I create a
symlink, I want the symlink to work the same regardless of the protocol
involved.

I think we can have our SMB2 symlinks and protect them too.  I'm not
suggesting we ignore security, so bear with me a moment. 

I propose we do the following:

 1. Limit creation of SMB2 symlinks to "admin list" users only.  That
    should resolve most of the symlink security problems, and is the
    recommendation for a windows box anyway:
    https://technet.microsoft.com/en-us/library/dn221947(v=ws.11).aspx
 2. If the SMB2 symlink is created by a trusted admin, create it as a
    trusted (or maybe user) EA on a file, just as you originally decided. 
     1. The trusted admins know what they want.  If they want a
        Windows-only traversable symlink resolved only by the client,
        they should be able to have it.
     2. The trusted admins can also create the Windows-only EA-based
        link on the server-side shell with setfattr.  This would allow
        setting other attributes/reparse-tags  for the other
        reparse-point types (HSM, DFS, user-defined values, etc) if such
        ever proves useful.
 3. If the file is a UNIX symlink that points to a wide-link target and
    options are enabled for wide links and follow symlinks, return an
    SMB2 symlink error with IO_REPARSE_TAG_MOUNT_POINT, so the client
    knows it is a server-resolved target, and it's free space
    information must be re-queried.


Item 3 is probably not perfect, but we are doing some exploratory coding
on it now to see if such a thing would be agreeable to the client.  I
think it would resolve the symlink disaster of two round trips to
resolve every symlink.

Our previous patch submission tried to add just
IO_REPARSE_TAG_MOUNT_POINT support in a general, non-protocol-dependent
way.  The logic was subtlety flawed, and I don't think the symlink error
struct was returned.  I think the general case handling would be better,
but a more agreeable way of detecting the mount-point crossing would be
needed.

Where the SMB2/FSCC symlink error struct handles both SMB2 symlinks and
mountpoint tags, they should probably be implemented together.

Comments welcome.