samba - Jan 2024 - Behavior of acl_xattr:ignore system acls = yes on a share

On 31.01.2024 9:13, Peter Milesson via samba wrote:
> Hi folks,
>
> No, it does not work. Sorry for the noise. See below.
>
>
> On 31.01.2024 8:51, Peter Milesson via samba wrote:
>> Hi folks,
>>
>> Thanks everybody for your information.
>>
>> I have continued my testing and have got the following to report:
>>
>> Setting up the share with either root:"Domain Admins", or 
>> "Administrator":"Domain Admins" as owner, while
setting permissions
>> on the share folder to 0777 from the start, and acl_xattr:ignore 
>> system acls = yes on the share definition in smb.conf (I did not 
>> forget to restart smbd and winbind)
>>
>> Then in Windows Computer management/Security I get the following list:
>> Owner: (root or Administrator)
>>
>> ?? root (or Administrator)??? Full Control??? This folder only
>> ?? Domain Admins??? Read, write & execute??? This folder only
>> ?? Everyone??? Read, write & execute??? This folder only
>> ?? SYSTEM??? Full Control??? This folder only
>>
>> Any change I make to the list ends with the error message "Failed
to
>> enumerate objects in the container. Access is denied" after
clicking OK.
>>
>> If I first make the basic setup of the share to my liking, without 
>> having acl_xattr:ignore system acls = yes active, and then reload 
>> smbd with acl_xattr:ignore system acls = yes, it seems to work.
>>
>> It does not seem important whether the linux permissions on the share 
>> folder are 0770 or 0777, or linux owner on the share folder being 
>> root or Administrator when setting it up. I have not investigated if 
>> the folder permissions are important for the share later on.
>>
>> Best regards,
>>
>> Peter
>>
>>
> Permissions set under Windows are not honored completely. As a user 
> with administrative privileges, I set a sub folder in the share to 
> full control for a group (even tried to change ownership). Then 
> logging in to Windows as a user belonging to that group, opening the 
> share, and trying to add something in that sub folder. It results in 
> access denied.
>
> I will continue to dig into this. Something is not working, or not 
> working according to documentation with ignore system acls = yes.
>
> Best regards,
>
> Peter
>
Hi folks,

Further testing.

I setup the share as Ralph suggested, share folder owner root:"Domain 
Admins", permissions 0777 and acl_xattr:ignore system acls = yes. I left 
the basic setup as it is (nothing can be changed anyway), and I get the 
following (as above) in Computer Management:

Owner: root
 ?? root??? Full Control??? This folder only
 ?? Domain Admins??? Read, write & execute??? This folder only
 ?? Everyone??? Read, write & execute??? This folder only
 ?? SYSTEM??? Full Control??? This folder only

Then I copy a bunch of files and folders to the share root, no problem. 
After that, I can set permissions on individual folders and files as I like.

The crucial problem here is, that Everyone (yes, really everyone) can 
write to the root share. I can protect existing files and folders with 
permissions, but it's impossible to stop Everyone from creating files in 
the share root, as it's not possible to change the basic share 
permissions. This makes the acl_xattr:ignore system acls = yes kind of 
pointless, and right out extremely dangerous in a production environment.

I hope I have overlooked something, and it turns out there is a way to 
set permissions on the share. In that case, I would be very grateful to 
get information on how this can be achieved.

Until then, I need to stick with shares defined without acl_xattr:ignore 
system acls = yes

Best regards,

Peter

On 1/31/24 09:50, Peter Milesson via samba wrote:
> The crucial problem here is, that Everyone (yes, really everyone) can 
> write to the root share. 
why don't you just change it? That's how it's supposed to work.

-slow

-- 
SerNet Samba Team Lead       https://samba.plus/
Samba Team Member             https://samba.org/
SAMBA+ packages              https://samba.plus/
SerNet Samba Support, Consulting and Development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20240131/b66b54f4/OpenPGP_signature.sig>