[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 :-)

that should be a core option since inherit acls / permissions in the 
configuration typically has a reason: shared access and users which are 
in more than one group

in case of netatalk "file perm" until now is much more than a wish - 
it's what really happens (until samba is part of the game and somebody 
over smbd is touching anything)