Peter Milesson
2024-Jan-31 08:13 UTC
[Samba] Behavior of acl_xattr:ignore system acls = yes on a share
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
Peter Milesson
2024-Jan-31 08:50 UTC
[Samba] 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
Maybe Matching Threads
- Behavior of acl_xattr:ignore system acls = yes on a share
- Behavior of acl_xattr:ignore system acls = yes on a share
- Behavior of acl_xattr:ignore system acls = yes on a share
- Behavior of acl_xattr:ignore system acls = yes on a share
- Behavior of acl_xattr:ignore system acls = yes on a share