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

[Alain Knaff (Samba Lists)]

On 05/08/2010 02:10 PM, Volker Lendecke wrote:
[...]
>> 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.?
> 
> Just to make sure I understand you right: You want Samba to
> report and follow existing wide links but not allow setting
> them at all from the client if wide links are enabled? This
> might indeed be a compromise. Jeremy should comment here.

Yes, indeed. That's the idea.

[...]
>> When was the wide links option introduced?
> 
> Ages ago.
> 
>> When was the unix extensions option introduced?
> 
> Later than wide links. But it is not always clear from the
> age of an option how popular it is. For example
> "security=user" came later than "security=share", but I
> would very much guess that security=user is the more popular
> one.

Agreed. But I guess the security=xxx option is more of an exceptional
case, as Samba was still in its infancy when security=user was introduced...

> 
>> What is the main purpose of samba?
> 
> To serve our users best. Unfortunately, it is not always
> possible to stay 100% compatible with all existing setups.

And I naively assumed that the main purpose of Samba was to serve shares
residing on Unix servers to Windows clients... It's nice if Unix boxes
can be clients too, but don't we have other tools for these cases (such
as NFS)...?

> In this case we had to make a choice for which users we have
> to cause trouble, and we decided to not break the users of
> unix extensions. It was just not possible technically to
> keep compatible with all setups.

The thing that shocked me in this instance was:
1. That "default" values would win over explicitly stated user choices
(but now I understand the technical reason behind this: parse order)
2. That a perceived "niche" use (unix extensions) was given priority
over a more mainstream use.

> All I can do is to express my regret about the grief we
> caused for you. We have really tried to do our best to make
> the consequences clear in our release notes. Unfortunately
> as a daemon Samba is not able to pop up a message after an
> upgrade to warn users about possible changes, so we have to
> rely on people reading release notes.

The thing is, many people get (what they think are) minor updates using
apt-get upgrade. And in most cases, these updates are indeed minor...
and too numerous to check the release notes for all of them...

> This might not in all
> cases be possible due to time restrictions in urgency
> situations, which is why minimize breaking existing setups
> at VERY high cost. But sometimes we have to just step on
> someones toes.
> 
> Volker

Regards,

Alain