[Samba] issue with allow insecure wide links

[Linda W]

Erik Hvatum wrote:
> avh <art <at> lsr.nei.nih.gov> writes:
>
>> I realize the security implications of wide links together with unix
>> extensions.  But the doc says that for those who want to do this setting the
>> "allow insecure wide links" will permit it.  However I found that Samba 3.6
>> on RHEL 6.5 does recognize this parameter but it has no effect.  
>>
>
> This old message happened to be the second search result returned by Google
> for "allow insecure wide links samba no effect"; I hope this reply proves as
> easy to find.
>
> In addition to enabling "allow insecure wide links" in global settings, you
> must also apply "wide links = yes" and "unix extensions = yes" to the shares
> with exterior links that you want to be followable.
----
You don't need 'unix extensions=yes' for *symlinks* to be followable on
a samba server.  'unix extensions' simply allow those symlinks to be
created from a client.  If clients can login and access their home
directories on the server (something that is likely if you use samba to
provide access to BOTH your windows and linux stations), they can create
**symlinks** that point anywhere.  Then simply allowing "wide
links=yes", will create the same security flaw that people think "allow
insecure wide links=no" will prevent.

The problem was never the symlinks, directly, but allowing clients to
create them by enabling 'unix extensions'.  I.e. the real insecurity was
in allowing 'unix extensions', that could allow creation of symlinks
from a client w/o server-login access.

But if you use Samba to control access to both windows and unix
machines, the same security flaw exists.

Your last paragraph might be more clear if you say that you must add
'wide links = yes' (unix extensions are irrelevant), to the shares where
you want to support *inter-share* symbolic links (i.e. symbolic links
that can point to another share).   I objected to the name "allow
insecure wide links", as there is no such thing on a unix machine.  What
it was preventing was "client-control" of symlinks on the share that
would point outside the share.  But the code that checks that is flakey
(I say that, because none of the files on my machine are outside of
a share, yet the "external check code" would often fail to catch this.

Instead, I rely on unix permissions  and ACL's to control access to
files -- not unreliable symbolic link breakage.

>  This part be may done on a per share basis - or globally, in which
>  case you might consider specifically setting "wide links = no" or
>  "unix extensions = no" for [homes].
---

Note -- setting "unix extensions=no" won't work if your servers
allow windows users to login to them, which I allow for.