Bailey Allison
2024-Jan-30 23:45 UTC
[Samba] Behavior of acl_xattr:ignore system acls = yes on a share
Just wanted to say very interesting thread! I would like to share my experience as well if that's alright. I have noticed when using the ignore system acls = yes value, when checking on the Windows side permissions it appears as the following (copying from Peter here): -Permissions list- root (Unix User\root) Full Control This folder only Domain Admins (Private\Domain Admins) Read, write & Execute This folder only SYSTEM Full control This folder only Note that the group assigned on the Linux side gets read write execute, and the user gets Full Control. What does this mean? On Windows, read write execute is not enough to modify permissions on files or folders, so anyone in Domain Admins can access but not administer permissions for the share (i.e add users or groups, modify permissions). With the above permissions the only user who can actually edit the permissions on the Windows side is root, which is most likely not a good idea. Also where root isn't (shouldn't?) be a domain user, and is a linux user this also does not help. Despite the underlying permissions being 0770 in this case, i.e user and group same on linux, they get interpreted differently on the Windows side. This could be an entirely Windows related thing, perhaps someone else can share their knowledge on this. I am assuming by changing to 0777 the idea is that anyone can modify permissions? But where's there is no entry for everyone, and Domain Admins is still getting listed as read write execute, not sure if this would work. I will check in on this. Checking in on this as I write the email, 0777 adds an entry for Everyone also as read write execute, which is not enough to modify the permissions on the Windows side. Peter, for your sake try assigning an admin account/your account as the owner user instead of root, and try modifying the permissions then to see if it works. You should see your account listed as Full Control, which should give you enough access to add and modify the permissions on Windows. Happy to be corrected if there's something I'm completely missing/am incorrect about! ? Regards, Bailey> -----Original Message----- > From: samba <samba-bounces at lists.samba.org> On Behalf Of Greg Sloop > <gregs--- via samba > Sent: January 30, 2024 6:33 PM > To: samba at lists.samba.org > Subject: Re: [Samba] Behavior of acl_xattr:ignore system acls = yes on a > share > > Perhaps everyone's clear on this - but I thought I should add this, just in case. > (And perhaps the clarification should be added to the wiki.) When it says > "Samba will ignore the standard Unix system ACL's (ugo)" > This is technically true. HOWEVER! > It only ignores the standard Unix system ACLS as it applies to SAMBA > permissions. > > This won't allow Samba to read files that the samba process can't read. > Thus, set them to 0777 so there are no restrictions at the file system level, > and then SAMBA will ignore the Unix ACL's for what permissions it gives to > *SAMBA* users, and apply them purely based on the extended acls set in > Windows, for example. > > (Wording that properly is not exactly easy, but hopefully that's helpful.) > > On Tue, Jan 30, 2024 at 12:24?PM Ralph Boehme via samba < > samba at lists.samba.org> wrote: > > > On 1/30/24 20:15, Peter Milesson via samba wrote: > > > *Setup shared folder* > > > > > > * Create the folder /data/migrtest > > > * Set ownership to root:"Domain Admins" > > > * chmod 0770 migrtest > > > > iirc this has to be 0777, otherwise the kernel gets in your way. You > > only want Samba to enforce permissions so you have to get the kernel > > filesystem permissions our of the way by goint with 0777. > > > > -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 > > > > -- > > To unsubscribe from this list go to the following URL and read the > > instructions: https://lists.samba.org/mailman/options/samba > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
Peter Milesson
2024-Jan-31 07:51 UTC
[Samba] Behavior of acl_xattr:ignore system acls = yes on a share
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
On 31.01.2024 0:45, Bailey Allison via samba wrote:> Just wanted to say very interesting thread! I would like to share my
experience as well if that's alright.
>
> I have noticed when using the ignore system acls = yes value, when checking
on the Windows side permissions it appears as the following (copying from Peter
here):
>
> -Permissions list-
> root (Unix User\root) Full Control This folder only Domain Admins
(Private\Domain Admins) Read, write & Execute This folder only SYSTEM
Full control This folder only
>
> Note that the group assigned on the Linux side gets read write execute, and
the user gets Full Control. What does this mean? On Windows, read write execute
is not enough to modify permissions on files or folders, so anyone in Domain
Admins can access but not administer permissions for the share (i.e add users or
groups, modify permissions). With the above permissions the only user who can
actually edit the permissions on the Windows side is root, which is most likely
not a good idea. Also where root isn't (shouldn't?) be a domain user,
and is a linux user this also does not help.
>
> Despite the underlying permissions being 0770 in this case, i.e user and
group same on linux, they get interpreted differently on the Windows side.
>
> This could be an entirely Windows related thing, perhaps someone else can
share their knowledge on this.
>
> I am assuming by changing to 0777 the idea is that anyone can modify
permissions? But where's there is no entry for everyone, and Domain Admins
is still getting listed as read write execute, not sure if this would work. I
will check in on this. Checking in on this as I write the email, 0777 adds an
entry for Everyone also as read write execute, which is not enough to modify the
permissions on the Windows side.
>
> Peter, for your sake try assigning an admin account/your account as the
owner user instead of root, and try modifying the permissions then to see if it
works. You should see your account listed as Full Control, which should give you
enough access to add and modify the permissions on Windows.
>
> Happy to be corrected if there's something I'm completely
missing/am incorrect about! ?
>
> Regards,
>
> Bailey
>
>
>> -----Original Message-----
>> From: samba<samba-bounces at lists.samba.org> On Behalf Of Greg
Sloop
>> <gregs--- via samba
>> Sent: January 30, 2024 6:33 PM
>> To:samba at lists.samba.org
>> Subject: Re: [Samba] Behavior of acl_xattr:ignore system acls = yes on
a
>> share
>>
>> Perhaps everyone's clear on this - but I thought I should add this,
just in case.
>> (And perhaps the clarification should be added to the wiki.) When it
says
>> "Samba will ignore the standard Unix system ACL's (ugo)"
>> This is technically true. HOWEVER!
>> It only ignores the standard Unix system ACLS as it applies to SAMBA
>> permissions.
>>
>> This won't allow Samba to read files that the samba process
can't read.
>> Thus, set them to 0777 so there are no restrictions at the file system
level,
>> and then SAMBA will ignore the Unix ACL's for what permissions it
gives to
>> *SAMBA* users, and apply them purely based on the extended acls set in
>> Windows, for example.
>>
>> (Wording that properly is not exactly easy, but hopefully that's
helpful.)
>>
>> On Tue, Jan 30, 2024 at 12:24?PM Ralph Boehme via samba <
>> samba at lists.samba.org> wrote:
>>
>>> On 1/30/24 20:15, Peter Milesson via samba wrote:
>>>> *Setup shared folder*
>>>>
>>>> * Create the folder /data/migrtest
>>>> * Set ownership to root:"Domain Admins"
>>>> * chmod 0770 migrtest
>>> iirc this has to be 0777, otherwise the kernel gets in your way.
You
>>> only want Samba to enforce permissions so you have to get the
kernel
>>> filesystem permissions our of the way by goint with 0777.
>>>
>>> -slow
>>>
>>> --
>>> SerNet Samba Team Leadhttps://samba.plus/
>>> Samba Team Memberhttps://samba.org/
>>> SAMBA+ packageshttps://samba.plus/
>>> SerNet Samba Support, Consulting and Development
>>>
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:https://lists.samba.org/mailman/options/samba
>>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:https://lists.samba.org/mailman/options/samba
>
Seemingly Similar 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