[PATCH] zfsacl: Fix ACL behavior issues with vfs_zfsacl

[Ralph Boehme]

Hi Andrew,

thanks a lot for the updated patch.

May I ask if you would be interested in submitting the patch via our
gitlab CI [1]? If you have a gitlab account, let me know so I can add
you to the project on gitlab.

I can of course run CI for you, but you wouldn't wanna miss the fun,
would you?

Thanks!
-slow


[1]
<https://wiki.samba.org/index.php/Samba_CI_on_gitlab#Other_Samba_developers>


On 7/1/19 1:59 PM, Andrew Walker via samba-technical wrote:
> Per Ralph's request, I am breaking the issues into separate patches. This
> is the first patch. It sets SEC_DESC_DACL_PROTECTED if the ZFS ACL lacks
> any entries with the INHERITED flag set. ZFS has the PROTECTED ACL flag,
> but mapping inside zfsacl is not possible because the flag in solaris /
> illumos is not exposed by the acl() syscall (although it is used by the
> kernel SMB server). In FreeBSD, the ACL flags are not mapped at all. I have
> a WIP patch for freebsd to expose them via acl_get_file() and
> acl_set_file(). This means that eventually I will submit a freebsd-specific
> vfs module to do this properly.
> 
> This behavior (being able to map SEC_DESC_DACL_PROTECTED to something)
> appears to be required for proper Windows client behavior when trying to
> alter an existing ACL. Windows Explorer will simply not allow users to edit
> an ACL if inheritance is not disabled. Unfortunately, it does not appear to
> evaluate the actual ACE inheritance flags to see if they are inherited, but
> rather at the security descriptor type bits. The end result is that it is
> impossible to use Windows explorer to edit the ACL of files in a Samba
> share with zfsacl unless this parameter is set.
> 
> Andrew
> 
> On Wed, May 29, 2019 at 1:02 PM Christof Schmitt <cs at samba.org> wrote:
> 
>> On Mon, May 27, 2019 at 11:34:17AM +0200, Ralph Boehme wrote:
>>> Hi Andrew,
>>>
>>> On 5/20/19 1:00 PM, Andrew Walker via samba-technical wrote:
>>>  > Thanks for the feedback and suggestions. I'll try to get this done
>> this
>>>> week or next week. You are correct that ZFS has the  NFSv4.1 ACL
>> flags, but
>>>> FreeBSD does not currently implement NFSv4.1 ACL inheritance. The
>>>> suggestion of just mapping what we receive over the wire is a good
>> one. I
>>>> could probably do this for the case of Solaris and Illumos.
>>>>
>>>> One possible alternative is that I could move this logic/lies to
>> libsunacl
>>>> (the library that maps ZFS ACLs to FreeBSD ACLs) so that there won't
>> be a
>>>> FreeBSD-specific parameter for vfs_zfsacl. In this case the only thing
>> I
>>>> would need to add to fix disabling inheritance in samba is mapping the
>>>> NFSv4.1 ACL flags to control flags like gpfs does.
>>>>
>>>> Let me know if you prefer the second approach.
>>>
>>> Not sure if I like either of both. :)
>>>
>>> Iirc the protected flag only comes to play client side, when Windows
>>> Explorer performs tree inheritance for new created ACEs. My NT ACL mind
>>> model is currently swapped out and not fully swapped back in, so I might
>>> be missing something. Jeremy?
>>>
>>> So basically the only thing you need to implement this in the filesystem
>>> is storing the flag, no need to attach any semantics to it in the
>>> filesystem. The chmod command could be updated to honor the flag when
>>> appyling ACL changes in directory tree mode, not sure if how GPFS
>>> handles this.
>>>
>>> Christof do you know? I guess chmod on GPFS will ignore the protected
>> flag.
>>
>> Is that the SEC_DESC_DACL_PROTECTED flag? For GPFS, gets mapped to
>> the ACL flag and stored in the file system ACL. There is no behavior
>> attached to that flag.
>>
>> chmod in vfs_gpfs does not check the PROTECTED flag. We probably could
>> add additional logic if necessary.
>>
>> Christof
>>


-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46