Am 2019-08-26 um 16:35 schrieb Rowland penny via samba:> On 26/08/2019 15:20, ? Peter Rindfuss via samba wrote: >> Hi, >> >> I have a question regarding permissions at the top of a share as seen >> from a Windows 10 client. >> >> We are using Samba 4.10.6-Debian (van Belle) on Debian 10 (Buster) with >> one AD controller and one file server. >> >> The top directory of our main share on the file server has, on the Linux >> level, these permissions reported by getfacl: >> # file: ... >> # owner: root >> # group: domain\040users >> # flags: --- >> user::rwx >> group::r-x >> other::--- >> >> i.e. there are no rights for "other" and no default entries in the Posix >> ACL (i.e. there is no Posix ACL at all, just plain Linux permissions) >> >> getfattr -d -e hex -m - ... >> shows user.DOSATTRIB="<something>", but no "security.NTACL=" and no >> "user.SAMBA_PAI=" >> >> The Windows security editor, however, has two entries for "Everyone": >> Allow Everyone None??? 'This folder only' >> Allow Everyone Special 'Subfolders and files only', the special rights >> being read permission. >> >> I am wondering where the read permission for 'Subfolders and files only' >> comes from as there is no trace of this on the Linux side. >> >> Thanks, Peter >> > Have you tried: getfattr -n security.NTACL -d /the/top/directory > > You have to explicitly ask for it. > > Unfortunately, you will not understand the output, so try this as well: > > samba-tool ntacl get /the top/directory --as-sddl > > Rowland > > >Thanks for your reply. The getfattr -d -e hex -m - (note the minus sign after the -m) does retrieve all existing attributes, including security.NTACL. It is simply not there at the share's top level. It is there for the subdirectories. getfattr -n security.NTACL -d /the/top/directory says /the/top/directory: security.NTACL: No such attribute samba-tool ntacl returns O:S-1-22-1-0G:DUD:(A;;0x001f01ff;;;S-1-22-1-0)(A;;0x001200a9;;;DU)(A;;;;;WD)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;0x001200a9;;;CG)(A;OICIIO;0x001200a9;;;WD) which is probably what I see in the Windows security tab. But what is this derived from? Peter
On 27/08/2019 09:58, ? Peter Rindfuss via samba wrote:> Am 2019-08-26 um 16:35 schrieb Rowland penny via samba: >> On 26/08/2019 15:20, ? Peter Rindfuss via samba wrote: >>> Hi, >>> >>> I have a question regarding permissions at the top of a share as seen >>> from a Windows 10 client. >>> >>> We are using Samba 4.10.6-Debian (van Belle) on Debian 10 (Buster) with >>> one AD controller and one file server. >>> >>> The top directory of our main share on the file server has, on the Linux >>> level, these permissions reported by getfacl: >>> # file: ... >>> # owner: root >>> # group: domain\040users >>> # flags: --- >>> user::rwx >>> group::r-x >>> other::--- >>> >>> i.e. there are no rights for "other" and no default entries in the Posix >>> ACL (i.e. there is no Posix ACL at all, just plain Linux permissions) >>> >>> getfattr -d -e hex -m - ... >>> shows user.DOSATTRIB="<something>", but no "security.NTACL=" and no >>> "user.SAMBA_PAI=" >>> >>> The Windows security editor, however, has two entries for "Everyone": >>> Allow Everyone None??? 'This folder only' >>> Allow Everyone Special 'Subfolders and files only', the special rights >>> being read permission. >>> >>> I am wondering where the read permission for 'Subfolders and files only' >>> comes from as there is no trace of this on the Linux side. >>> >>> Thanks, Peter >>> >> Have you tried: getfattr -n security.NTACL -d /the/top/directory >> >> You have to explicitly ask for it. >> >> Unfortunately, you will not understand the output, so try this as well: >> >> samba-tool ntacl get /the top/directory --as-sddl >> >> Rowland >> >> >> > Thanks for your reply. The getfattr -d -e hex -m - (note the minus sign > after the -m) does retrieve all existing attributes, including > security.NTACL. It is simply not there at the share's top level. It is > there for the subdirectories. > getfattr -n security.NTACL -d /the/top/directory says > /the/top/directory: security.NTACL: No such attribute > > samba-tool ntacl returns > O:S-1-22-1-0G:DUD:(A;;0x001f01ff;;;S-1-22-1-0)(A;;0x001200a9;;;DU)(A;;;;;WD)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;0x001200a9;;;CG)(A;OICIIO;0x001200a9;;;WD) > which is probably what I see in the Windows security tab. But what is > this derived from?The 'thing' your getfattr cannot find, 'security.NTACL' Your sddl decodes as this: O:S-1-22-1-0 root G:DU Domain Users D: (A;;0x001f01ff;;;S-1-22-1-0) allow;;Full control;;root (A;;0x001200a9;;;DU) allow;;Read only;;Domain Users (A;;;;;WD) allow;;;;EVERYONE (A;OICIIO;0x001f01ff;;;CO) allow;OBJECT_INHERIT CONTAINER_INHERIT INHERIT_ONLY;Full control;;;CREATOR_OWNER (A;OICIIO;0x001200a9;;;CG) allow;OBJECT_INHERIT CONTAINER_INHERIT INHERIT_ONLY;Read only;;;CREATOR_GROUP (A;OICIIO;0x001200a9;;;WD) allow;OBJECT_INHERIT CONTAINER_INHERIT INHERIT_ONLY;Read only;;;EVERYONE Rowland
On 27/08/2019 15:02, ? Peter Rindfuss wrote:> Am 2019-08-27 um 11:29 schrieb Rowland penny via samba: >> On 27/08/2019 09:58, ? Peter Rindfuss via samba wrote: >>> Am 2019-08-26 um 16:35 schrieb Rowland penny via samba: >>>> On 26/08/2019 15:20, ? Peter Rindfuss via samba wrote: >>>>> Hi, >>>>> >>>>> I have a question regarding permissions at the top of a share as seen >>>>> from a Windows 10 client. >>>>> >>>>> We are using Samba 4.10.6-Debian (van Belle) on Debian 10 (Buster) with >>>>> one AD controller and one file server. >>>>> >>>>> The top directory of our main share on the file server has, on the >>>>> Linux >>>>> level, these permissions reported by getfacl: >>>>> # file: ... >>>>> # owner: root >>>>> # group: domain\040users >>>>> # flags: --- >>>>> user::rwx >>>>> group::r-x >>>>> other::--- >>>>> >>>>> i.e. there are no rights for "other" and no default entries in the >>>>> Posix >>>>> ACL (i.e. there is no Posix ACL at all, just plain Linux permissions) >>>>> >>>>> getfattr -d -e hex -m - ... >>>>> shows user.DOSATTRIB="<something>", but no "security.NTACL=" and no >>>>> "user.SAMBA_PAI=" >>>>> >>>>> The Windows security editor, however, has two entries for "Everyone": >>>>> Allow Everyone None??? 'This folder only' >>>>> Allow Everyone Special 'Subfolders and files only', the special rights >>>>> being read permission. >>>>> >>>>> I am wondering where the read permission for 'Subfolders and files >>>>> only' >>>>> comes from as there is no trace of this on the Linux side. >>>>> >>>>> Thanks, Peter >>>>> >>>> Have you tried: getfattr -n security.NTACL -d /the/top/directory >>>> >>>> You have to explicitly ask for it. >>>> >>>> Unfortunately, you will not understand the output, so try this as well: >>>> >>>> samba-tool ntacl get /the top/directory --as-sddl >>>> >>>> Rowland >>>> >>>> >>>> >>> Thanks for your reply. The getfattr -d -e hex -m -? (note the minus sign >>> after the -m) does retrieve all existing attributes, including >>> security.NTACL. It is simply not there at the share's top level. It is >>> there for the subdirectories. >>> getfattr -n security.NTACL -d /the/top/directory says >>> /the/top/directory: security.NTACL: No such attribute >>> >>> samba-tool ntacl returns >>> O:S-1-22-1-0G:DUD:(A;;0x001f01ff;;;S-1-22-1-0)(A;;0x001200a9;;;DU)(A;;;;;WD)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;0x001200a9;;;CG)(A;OICIIO;0x001200a9;;;WD) >>> >>> which is probably what I see in the Windows security tab. But what is >>> this derived from? >> The 'thing' your getfattr cannot find, 'security.NTACL' > It's not hidden, it does not exist. I used your version of getfattr, see > above. getfattr shows 'security.NTACL' for other directories. > > PeterIf you have set the permissions from Windows then it should exist and look similar to this: root at dc4:~# getfattr -n security.NTACL /var/lib/samba/sysvol getfattr: Removing leading '/' from absolute path names # file: var/lib/samba/sysvol security.NTACL=0sBAAEAAAAAgAEAAIAAQCp6am1GotJOBGWqEzbx+jV69lfEcBxseIm2q6pPixE2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcG9zaXhfYWNsAHpBkx0YKNQBTqxeNQHOuh/c/z6YZFTuQjad7CmDVREUbsXeqk0EOGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAFJS0AAAAxAAAAAAAAADQAAAAAQIAAAAAAAUgAAAAIAIAAAEBAAAAAAAFEgAAAAQAzAAJAAAAAAsUAAAADOABAQAAAAAAAwAAAAAACxQAAAAAoAEBAAAAAAAFCwAAAAAAFACpABIAAQEAAAAAAAULAAAAAAsUAAAAABABAQAAAAAABRIAAAAAABQA/wMfAAEBAAAAAAAFEgAAAAALGAAAAAzgAQIAAAAAAAUgAAAAIAIAAAAAGAC/AR4AAQIAAAAAAAUgAAAAIAIAAAALGAAAAACgAQIAAAAAAAUgAAAAJQIAAAAAGACpABIAAQIAAAAAAAUgAAAAJQIAAA= Rowland
Am 2019-08-27 um 16:39 schrieb Rowland penny via samba:> On 27/08/2019 15:02, ? Peter Rindfuss wrote: >> Am 2019-08-27 um 11:29 schrieb Rowland penny via samba: >>> On 27/08/2019 09:58, ? Peter Rindfuss via samba wrote: >>>> Am 2019-08-26 um 16:35 schrieb Rowland penny via samba: >>>>> On 26/08/2019 15:20, ? Peter Rindfuss via samba wrote: >>>>>> Hi, >>>>>> >>>>>> I have a question regarding permissions at the top of a share as seen >>>>>> from a Windows 10 client. >>>>>> >>>>>> We are using Samba 4.10.6-Debian (van Belle) on Debian 10 (Buster) >>>>>> with >>>>>> one AD controller and one file server. >>>>>> >>>>>> The top directory of our main share on the file server has, on the >>>>>> Linux >>>>>> level, these permissions reported by getfacl: >>>>>> # file: ... >>>>>> # owner: root >>>>>> # group: domain\040users >>>>>> # flags: --- >>>>>> user::rwx >>>>>> group::r-x >>>>>> other::--- >>>>>> >>>>>> i.e. there are no rights for "other" and no default entries in the >>>>>> Posix >>>>>> ACL (i.e. there is no Posix ACL at all, just plain Linux permissions) >>>>>> >>>>>> getfattr -d -e hex -m - ... >>>>>> shows user.DOSATTRIB="<something>", but no "security.NTACL=" and no >>>>>> "user.SAMBA_PAI=" >>>>>> >>>>>> The Windows security editor, however, has two entries for "Everyone": >>>>>> Allow Everyone None??? 'This folder only' >>>>>> Allow Everyone Special 'Subfolders and files only', the special >>>>>> rights >>>>>> being read permission. >>>>>> >>>>>> I am wondering where the read permission for 'Subfolders and files >>>>>> only' >>>>>> comes from as there is no trace of this on the Linux side. >>>>>> >>>>>> Thanks, Peter >>>>>> >>>>> Have you tried: getfattr -n security.NTACL -d /the/top/directory >>>>> >>>>> You have to explicitly ask for it. >>>>> >>>>> Unfortunately, you will not understand the output, so try this as >>>>> well: >>>>> >>>>> samba-tool ntacl get /the top/directory --as-sddl >>>>> >>>>> Rowland >>>>> >>>>> >>>>> >>>> Thanks for your reply. The getfattr -d -e hex -m -? (note the minus >>>> sign >>>> after the -m) does retrieve all existing attributes, including >>>> security.NTACL. It is simply not there at the share's top level. It is >>>> there for the subdirectories. >>>> getfattr -n security.NTACL -d /the/top/directory says >>>> /the/top/directory: security.NTACL: No such attribute >>>> >>>> samba-tool ntacl returns >>>> O:S-1-22-1-0G:DUD:(A;;0x001f01ff;;;S-1-22-1-0)(A;;0x001200a9;;;DU)(A;;;;;WD)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;0x001200a9;;;CG)(A;OICIIO;0x001200a9;;;WD) >>>> >>>> >>>> which is probably what I see in the Windows security tab. But what is >>>> this derived from? >>> The 'thing' your getfattr cannot find, 'security.NTACL' >> It's not hidden, it does not exist. I used your version of getfattr, see >> above. getfattr shows 'security.NTACL' for other directories. >> >> Peter > > If you have set the permissions from Windows then it should exist and > look similar to this: > > root at dc4:~# getfattr -n security.NTACL /var/lib/samba/sysvol > getfattr: Removing leading '/' from absolute path names > # file: var/lib/samba/sysvol > security.NTACL=0sBAAEAAAAAgAEAAIAAQCp6am1GotJOBGWqEzbx+jV69lfEcBxseIm2q6pPixE2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcG9zaXhfYWNsAHpBkx0YKNQBTqxeNQHOuh/c/z6YZFTuQjad7CmDVREUbsXeqk0EOGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAFJS0AAAAxAAAAAAAAADQAAAAAQIAAAAAAAUgAAAAIAIAAAEBAAAAAAAFEgAAAAQAzAAJAAAAAAsUAAAADOABAQAAAAAAAwAAAAAACxQAAAAAoAEBAAAAAAAFCwAAAAAAFACpABIAAQEAAAAAAAULAAAAAAsUAAAAABABAQAAAAAABRIAAAAAABQA/wMfAAEBAAAAAAAFEgAAAAALGAAAAAzgAQIAAAAAAAUgAAAAIAIAAAAAGAC/AR4AAQIAAAAAAAUgAAAAIAIAAAALGAAAAACgAQIAAAAAAAUgAAAAJQIAAAAAGACpABIAAQIAAAAAAAUgAAAAJQIAAA=> >Thanks again. Fact was that permissions had never been set via Windows; only Linux permissions existed. In the meantime, I have set some reasonable permissions from Windows, and all looks good. Peter