[Samba] Feedback request on a tentative proposal to enhance smb.conf symlink-related params

[Jeremy Allison]

On Thu, Mar 01, 2018 at 10:48:02AM +0000, Stilez Stilezy wrote:
> As mentioned in another thread, I notice that the params used to control
> symlinks feel a bit inefficient and inelegant, and quite limited.  I think
> there might be a good opportunity to simplify and also make their management in
> Samba more powerful and adaptable to use-cases.  I'm guessing this list is a
> good enough starting point to propose a smb.conf param change to this area and
> see what reactions it gets.
>  
>  
> The issue:
>  
> Currently symlink handling uses 3 parameters:
>  
>  - "follow symlinks" (are they followed at all?)
>  - "wide links" (if so, can they be traversed to a location that isn't a child
> of the share root dir? Effectively "read/traverse but not write" restriction)
>  - "allow insecure links" (effectively "non-write restriction" removed, user
> can write wide links to arbitrary dirs. as well as follow them)
>  
> Limitations/opacity caused by the current options:
>  
> 1. These three params have slightly opaque names ("wide links" doesn't say
> *what* about wide links is/isn't altered by the option), and only certain
> combinations make sense. Implication:  smb.conf could combine them to good
> effect, simplifying the config, and also being clearer about how they relate to
> each other.
>  
> 2. There is no granularity about where symlinks can link to. The only
> granularity within Samba is to restrict read/traversal/create to either * a
> descendant of /dir/share, or * a descendant of / (=universal access). There's
> no other restriction setup possible within smb.conf. An implication is that
> it's impossible to include a directive that restricts symlink use+creation to
> specified locations outside the share root, other than by allowing them to have
> scope over the entire of /. For example, a if the file system separates user
> home and "generally available files", or has a virtual file system made up of
> dynamically updated symlinks, the user can't create symlinks unless these are
> all under the same share root, in which case the file system is forced to allow
> symlinks to dirs. that might not be desirable. Alternatively if they aren't
> under a common share root the user can't maintain symlinks as the only
> directive available gives permission to create links to anywhere. It's very
> crude.
>  
>  
> Tentative ideas for discussion:
>  
> Replace the current symlink handling directives by directives modelled on valid
> /invalid hosts+users:
> 
>     valid symlink targets = follow:<mask>, <mask>, <mask> ... [create:] <mask>,
>     <mask>, <mask>, ...
>     invalid symlink targets = follow:<mask>, <mask>, <mask> ... [create:]
>     <mask>, <mask>, <mask>, ...
>      
>     <mask> is built as usual from % substitutions,
>     default for each share is   valid symlink targets = follow:%P, create:%P

This would be too expensive to implement in the server
and is too much complexity for very little gain.

The reason is as follows. The server doesn't actually
read symlinks component by component - what it does is
find the last component in a client requested path, and
chdir() into that.

It then does a realpath() and checks if it is underneath
the share path= parameter, and if "wide links = no" and it
is not, refuses any further processing of the pathname.