Disabling of "wide links" violates "principle of least surprise"

[Volker Lendecke]

Hi!

Due to the issue being raised as a severe security issue, we
had to do something pretty quickly. We had to break either
the clients depending on unix extensions (Linux, OS/X) or
the ones depending on wide links.

On Fri, May 07, 2010 at 11:14:44PM +0200, Alain Knaff wrote:
> I'm not sure whether this is the right place to post this, if not please
> point me to the exact appropriate list or forum.
> 
> Recently, after doing what we thought was a routine update of our 9.04
> Ubuntu server (getting security updates and "minor" fixes), we were
> surprised that suddenly our read-only netlogon share was no longer working.
> 
> During the 2 hours that it took to investigate the problem, hundreds of
> our users were stuck without their default drives (which are mapped by
> the logon script set in smb.conf)
> 
> It turned out that the reason for the problem was that we had symlinks
> in our netlogon share, pointing to scripts called by our main script.
> 
> Thanks to a "wide links = yes" in the netlogon share definition, these
> had been working without a problem for many years.
> 
> Apparently, now this _explicit_ statement is being disabled because it
> conflicts with the _implicit_ default "unix extensions = yes".
> 
> Our config file mentions unix extensions nowhere, and until this
> episode, nobody on our site was even aware that such an option exists at
> all.
> 
> In order to save other sites similar grief, may I suggest the following:
> 1. always make it so that explicitly specified config settings have
> priority over any implicit defaults.

Unfortunately this does not work in here, as "unix
extensions" due to the protocol is a global parameter while
"wide links" is a share one. When we find the "wide links"
one being explicitly set, it is already too late, we have
already announce unix extensions.

> 2. or, if above is too complicated to implement, make it so that more
> well-known, or older options (that are more likely to be in wide,
> wanted, use) have priority over the new and more obscure options.

This is a bit hard to argue into either direction. We don't
really know which of the options are more popular. We had to
break someones setup, sorry that it hit you.

> 3. [in order to solve this particular conflict], maybe the exclusion
> could be lifted on read-only shares (... as the security problem only
> exists if users are actually able to create rogue links...)

Yes, this might technically be an option, but it would
become pretty confusing given the "write list" parameter.
Some users can see wide links, some can't. That would
probably cause more confusion than it solves.

Hope that helps,

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100508/ddd0eba9/attachment.pgp>