samba - Jan 2017 - vfs_fruit 'other' create mode different than parent

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

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

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)

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"