[Samba] vfs_fruit 'other' create mode different than parent

[Reindl Harald]

Am 23.01.2017 um 20:10 schrieb Jeremy Allison:
> On Mon, Jan 23, 2017 at 08:00:07PM +0100, Reindl Harald via samba wrote:
>> Am 23.01.2017 um 19:54 schrieb Ralph Böhme via samba:
>>> On Mon, Jan 23, 2017 at 11:49:15AM -0600, Chad William Seys wrote:
>>>> Hi Ralph,
>>>>> it's a global option. Have you put it in the global or a share section?
>>>>
>>>>  Thanks for the hint!  After putting it in the global options the create
>>>> mode mimics the parent directory as one would expect from
>>>> "
>>>> inherit permissions = yes
>>>> inherit acls = yes
>>>> "
>>>>
>>>> If possible it would be less dangerous (securitywise) not to have
>>>> fruit:nfs_aces setting interact with 'inherit permissions' and 'inherit
>>>> acls'.
>>>>
>>>> Or at least the default setting of nfs_aces should not interact with a big
>>>> warning/explanation of how changing to nfs_aces = yes will interact.
>>>
>>> well, the thing is, inheritance works as designed with fruit:nfs_aces=yes, it's
>>> just that the client changes permissions *after* the fact...
>>
>> it would be really helpful when samba would have a param to ignore
>> any permission changes from the client - each time when we have
>> access problems is because some idiotic client changed them instead
>> leave the smb server in peace with it's for good reason chosen
>> defaults
>
> Hmmm. You could do that with a VFS module that just returns
> NT_STATUS_OK for any set_nt_acl() call, but doesn't do anything
> with the incoming data :-)

frankly that happens even when "nt acl support = no" is set

you don't see the permissions tab on windows explorer, but if you copy a 
file from a win7 desktop to a smb share the resulting permissions are 
chosen by god and then you even hae no way to fix it execpt delete the 
file from the share, give "everyone" permissions on the local file and 
upload it again

"nt acl support = no" is a clear indication of "dear client shut up"