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

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.

Thanks again!
Chad.

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

Maybe we could switch fruit:nfs_aces to no at runtime based on the inherit
settings. Thoughts?

Cheerio!
-slow

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

> well, the thing is, inheritance works as designed with fruit:nfs_aces=yes,
it's
> just that the client changes permissions *after* the fact...
How icky.  Is it b/c mac's don't understand the Linux (posix?) extended 
acl?  I suppose Samba cannot tell when the client is changing the 
permissions as a misunderstanding versus purposefully?  E.g. is the 
pattern of requests different?
> Maybe we could switch fruit:nfs_aces to no at runtime based on the inherit
> settings. Thoughts?
Yeah, that would work, but it is harder to explain.
I also don't know what people who would set 'fruit:nfs_aces = yes' 
expect.  Would they also want the 'inherit *' to be 'no'?

Does it make sense that some combos of the settings are mutually exclusive?

Thanks!
C.