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

[Alain Knaff (Samba Lists)]

On 05/08/2010 01:09 PM, Volker Lendecke wrote:
[...]
>> 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.

1. Would it be possible to change the order of option parsing? Or do
some kind of double pass over the file to handle these situations?
2. Why not handle it the same way as read-only is handled:

We have a share declared as follows:

[netlogon]
        comment = Network Logon Service
        path=/samba/netlogon/%G
        browseable = yes
        writeable = no
        guest ok = no

... and we get:

root at hal:~# smbclient //hal/netlogon -U aknaff
Password:
Domain=[INFO] OS=[Unix] Server=[Samba 3.0.28a]
smb: \> link /etc etc
NT_STATUS_NETWORK_ACCESS_DENIED linking files (\etc -> \/etc)
smb: \>

So, if it is possible to make symlinking unavailable for "writeable =
no", why shouldn't it be possible to make it unavailable if "wide links
= yes" is set.?

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

When was the wide links option introduced?
When was the unix extensions option introduced?
What is the main purpose of samba?

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

Agreed. So maybe only do this is the share has "writeable = no" or "read
only = yes", but no write list.

> 
> Hope that helps,
> 
> Volker

Thanks,

Alain