Sebastian Arcus
2019-Jun-11 13:54 UTC
[Samba] Problems with inconsistent ACL inheritance and permissions after Samba upgrade
On 11/06/19 13:29, Rowland penny via samba wrote:> On 11/06/2019 13:13, Sebastian Arcus via samba wrote: >> >> On 11/06/19 11:49, Rowland penny via samba wrote: >>> On 11/06/2019 11:38, Sebastian Arcus via samba wrote: >>>> >>>> On 11/06/19 11:07, Rowland penny via samba wrote: >>>>> On 11/06/2019 10:34, Sebastian Arcus via samba wrote: >>>>>> I've just upgraded a Samba AD server to 4.10.2 a few weeks ago >>>>>> from 4.x (I'm afraid I'm not sure the exact earlier version) - and >>>>>> since then I just haven't managed to pin down the file permissions >>>>>> and inheritance on the shares as it's been constantly causing >>>>>> issues. This server is both a file server and a AD DC. >>>>>> >>>>>> The current problem I am facing is the permissions of the lock >>>>>> file generated by Microsoft Access (.ldb). The Access database is >>>>>> on the server share. When one Windows client opens it, the .ldb >>>>>> file is created with group write permission (-rw-rw----). But when >>>>>> it is opened from another Windows machine, the .ldb file is >>>>>> created with group read-only permissions (-rw-r-----) - which >>>>>> locks other users out. There seems to be a mask applied, but I >>>>>> have no idea where is it coming from. Both client machines are >>>>>> Windows 7 - I just can't figure out the reason. It used to work >>>>>> fine before the Samba upgrade. The wrong acl's for the .ldb file >>>>>> look like this: >>>>>> >>>>>> # file: praxis_be.ldb >>>>>> # owner: HEBI\\user1 >>>>>> # group: HEBI\\domain\040users >>>>>> user::rw- >>>>>> user:root:rwx??????????? #effective:r-- >>>>>> group::rwx??????????? #effective:r-- >>>>>> group:HEBI\\domain\040users:rwx??? #effective:r-- >>>>>> group:HEBI\\domain\040computers:r-x??? #effective:r-- >>>>>> mask::r-- >>>>>> other::--- >>>>>> >>>>>> >>>>>> What I've tried: >>>>>> >>>>>> 1. I have set and reset the acl's on the Linux side for the share >>>>>> and parent dir (the lock file is in the root of the network share) >>>>>> - and made sure it doesn't have a mask: >>>>> >>>>> You should stop doing this, as it is a DC, you need to set the >>>>> permissions from Windows, see here: >>>>> >>>>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs >>>> >>>> Thank you for the quick answer. I should have mentioned that I tried >>>> that as well. Could you confirm if "inherit acls" and "create mask" >>>> and "directory mask" should still apply to Samba in AD mode any more >>>> - or not? >>>> >>>> >>> Your share on the DC should only be this: >>> >>> [praxis] >>> path = /srv/samba/praxis >>> read only = No >>> >>> You shouldn't add anything else, it has always been this way on a DC. >> >> Yes - that's what I read in the docs - and that's what I started with. >> But that's when I don't get the expected ACL inheritance. I just >> trimmed the share definition down again to the above, and when I >> created a dir, the mask kicks in again: >> >> # file: test3 >> # owner: root >> # group: HEBI\\domain\040users >> # flags: -s- >> user::rwx >> user:root:rwx??????????? #effective:r-x >> user:3000017:r-x >> group::rwx??????????? #effective:r-x >> group:HEBI\\domain\040users:rwx??? #effective:r-x >> group:HEBI\\domain\040computers:r-x >> mask::r-x >> other::--- >> default:user::rwx >> default:user:root:rwx >> default:user:3000017:r-x >> default:group::rwx >> default:group:HEBI\\domain\040users:rwx >> default:group:HEBI\\domain\040computers:r-x >> default:mask::rwx >> default:other::--- >> >> >> Is the mask coming from the local Linux filesystem umask? If yes, >> shouldn't the ACL's supersede it? >> >>> I think it might help if you posted the global part of the smb.conf >> >> Sure: >> >> >> [global] >> bind interfaces only = Yes >> interfaces = lo eth1 tun0 tun1 >> netbios name = HEBI-SERVER >> realm = HEBI.LAN >> server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, >> winbindd, ntp_signd, kcc, dnsupdate >> workgroup = HEBI >> server role = active directory domain controller >> idmap_ldb:use rfc2307 = yes >> comment >> >> log file = /var/log/samba/%m.log >> max log size = 1000 >> >> mangling method = hash2 >> mangle prefix = 6 >> reset on zero vc = yes >> deadtime = 10 >> >> >> load printers = yes >> rpc_server:spoolss = external >> rpc_daemon:spoolssd = fork >> > Would it help if I told you that you are reading the wrong permissions ?That kind of helps, in the sense that I never realised that there are two sets of ACL's stored in two different places. I have just re-read for the n-th time the https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs and I'm still trying to get my head around it. I guess that means the real permissions (seen on the Windows side) are made up of Linux ACL's *plus* the extended attributes stored by Samba elsewhere? Also, it doesn't quite solve the problem, as the "Domain Users" still gets no permissions whatsoever when creating new dirs, in spite of the fact that the parent dir has full permissions for "Domain Users" (on the Windows side).
Sebastian Arcus
2019-Jun-11 15:44 UTC
[Samba] Problems with inconsistent ACL inheritance and permissions after Samba upgrade
On 11/06/19 14:54, Sebastian Arcus via samba wrote:> > On 11/06/19 13:29, Rowland penny via samba wrote: >> On 11/06/2019 13:13, Sebastian Arcus via samba wrote: >>> >>> On 11/06/19 11:49, Rowland penny via samba wrote: >>>> On 11/06/2019 11:38, Sebastian Arcus via samba wrote: >>>>> >>>>> On 11/06/19 11:07, Rowland penny via samba wrote: >>>>>> On 11/06/2019 10:34, Sebastian Arcus via samba wrote: >>>>>>> I've just upgraded a Samba AD server to 4.10.2 a few weeks ago >>>>>>> from 4.x (I'm afraid I'm not sure the exact earlier version) - >>>>>>> and since then I just haven't managed to pin down the file >>>>>>> permissions and inheritance on the shares as it's been constantly >>>>>>> causing issues. This server is both a file server and a AD DC. >>>>>>> >>>>>>> The current problem I am facing is the permissions of the lock >>>>>>> file generated by Microsoft Access (.ldb). The Access database is >>>>>>> on the server share. When one Windows client opens it, the .ldb >>>>>>> file is created with group write permission (-rw-rw----). But >>>>>>> when it is opened from another Windows machine, the .ldb file is >>>>>>> created with group read-only permissions (-rw-r-----) - which >>>>>>> locks other users out. There seems to be a mask applied, but I >>>>>>> have no idea where is it coming from. Both client machines are >>>>>>> Windows 7 - I just can't figure out the reason. It used to work >>>>>>> fine before the Samba upgrade. The wrong acl's for the .ldb file >>>>>>> look like this: >>>>>>> >>>>>>> # file: praxis_be.ldb >>>>>>> # owner: HEBI\\user1 >>>>>>> # group: HEBI\\domain\040users >>>>>>> user::rw- >>>>>>> user:root:rwx??????????? #effective:r-- >>>>>>> group::rwx??????????? #effective:r-- >>>>>>> group:HEBI\\domain\040users:rwx??? #effective:r-- >>>>>>> group:HEBI\\domain\040computers:r-x??? #effective:r-- >>>>>>> mask::r-- >>>>>>> other::--- >>>>>>> >>>>>>> >>>>>>> What I've tried: >>>>>>> >>>>>>> 1. I have set and reset the acl's on the Linux side for the share >>>>>>> and parent dir (the lock file is in the root of the network >>>>>>> share) - and made sure it doesn't have a mask: >>>>>> >>>>>> You should stop doing this, as it is a DC, you need to set the >>>>>> permissions from Windows, see here: >>>>>> >>>>>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs >>>>>> >>>>> >>>>> Thank you for the quick answer. I should have mentioned that I >>>>> tried that as well. Could you confirm if "inherit acls" and "create >>>>> mask" and "directory mask" should still apply to Samba in AD mode >>>>> any more - or not? >>>>> >>>>> >>>> Your share on the DC should only be this: >>>> >>>> [praxis] >>>> path = /srv/samba/praxis >>>> read only = No >>>> >>>> You shouldn't add anything else, it has always been this way on a DC. >>> >>> Yes - that's what I read in the docs - and that's what I started >>> with. But that's when I don't get the expected ACL inheritance. I >>> just trimmed the share definition down again to the above, and when I >>> created a dir, the mask kicks in again: >>> >>> # file: test3 >>> # owner: root >>> # group: HEBI\\domain\040users >>> # flags: -s- >>> user::rwx >>> user:root:rwx??????????? #effective:r-x >>> user:3000017:r-x >>> group::rwx??????????? #effective:r-x >>> group:HEBI\\domain\040users:rwx??? #effective:r-x >>> group:HEBI\\domain\040computers:r-x >>> mask::r-x >>> other::--- >>> default:user::rwx >>> default:user:root:rwx >>> default:user:3000017:r-x >>> default:group::rwx >>> default:group:HEBI\\domain\040users:rwx >>> default:group:HEBI\\domain\040computers:r-x >>> default:mask::rwx >>> default:other::--- >>> >>> >>> Is the mask coming from the local Linux filesystem umask? If yes, >>> shouldn't the ACL's supersede it? >>> >>>> I think it might help if you posted the global part of the smb.conf >>> >>> Sure: >>> >>> >>> [global] >>> bind interfaces only = Yes >>> interfaces = lo eth1 tun0 tun1 >>> netbios name = HEBI-SERVER >>> realm = HEBI.LAN >>> server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, >>> winbindd, ntp_signd, kcc, dnsupdate >>> workgroup = HEBI >>> server role = active directory domain controller >>> idmap_ldb:use rfc2307 = yes >>> comment >>> >>> log file = /var/log/samba/%m.log >>> max log size = 1000 >>> >>> mangling method = hash2 >>> mangle prefix = 6 >>> reset on zero vc = yes >>> deadtime = 10 >>> >>> >>> load printers = yes >>> rpc_server:spoolss = external >>> rpc_daemon:spoolssd = fork >>> >> Would it help if I told you that you are reading the wrong permissions ? > > That kind of helps, in the sense that I never realised that there are > two sets of ACL's stored in two different places. I have just re-read > for the n-th time the > https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs > and I'm still trying to get my head around it. I guess that means the > real permissions (seen on the Windows side) are made up of Linux ACL's > *plus* the extended attributes stored by Samba elsewhere? > > Also, it doesn't quite solve the problem, as the "Domain Users" still > gets no permissions whatsoever when creating new dirs, in spite of the > fact that the parent dir has full permissions for "Domain Users" (on the > Windows side).Ok - I might have at least a partial answer. Somehow the default mask in Samba still seems to be obeyed - even in AD mode. It seems to lack by default the 'write' bit - which gets removed from the permissions when creating a new directory. Without any additional share settings in smb.conf, a new subdirectory gets created with the following two sets of permissions, no matter what I try: "Domain users" - Traverse, Read attributes, Read extended attributes - This folder only "Domain users" - Full Control - Subfolders and files only If I add the following settings in smb.conf for the share: create mask = 0660 directory mask = 0770 Then finally the Windows permissions for a new subdirectory are as expected - just one set for "Domain Users": "Domain Users" - Full Control - This folder, subfolders and files It seems the the Samba default umask limits the ACL permissions it grants on the Windows side to new files and folders. Could this be a bug - as it doesn't seem to be mentioned anywhere in the docs?
Sebastian Arcus
2019-Jun-13 16:54 UTC
[Samba] Problems with inconsistent ACL inheritance and permissions after Samba upgrade
On 11/06/19 16:44, Sebastian Arcus via samba wrote:> > On 11/06/19 14:54, Sebastian Arcus via samba wrote: >> >> On 11/06/19 13:29, Rowland penny via samba wrote: >>> On 11/06/2019 13:13, Sebastian Arcus via samba wrote: >>>> >>>> On 11/06/19 11:49, Rowland penny via samba wrote: >>>>> On 11/06/2019 11:38, Sebastian Arcus via samba wrote: >>>>>> >>>>>> On 11/06/19 11:07, Rowland penny via samba wrote: >>>>>>> On 11/06/2019 10:34, Sebastian Arcus via samba wrote: >>>>>>>> I've just upgraded a Samba AD server to 4.10.2 a few weeks ago >>>>>>>> from 4.x (I'm afraid I'm not sure the exact earlier version) - >>>>>>>> and since then I just haven't managed to pin down the file >>>>>>>> permissions and inheritance on the shares as it's been >>>>>>>> constantly causing issues. This server is both a file server and >>>>>>>> a AD DC. >>>>>>>> >>>>>>>> The current problem I am facing is the permissions of the lock >>>>>>>> file generated by Microsoft Access (.ldb). The Access database >>>>>>>> is on the server share. When one Windows client opens it, the >>>>>>>> .ldb file is created with group write permission (-rw-rw----). >>>>>>>> But when it is opened from another Windows machine, the .ldb >>>>>>>> file is created with group read-only permissions (-rw-r-----) - >>>>>>>> which locks other users out. There seems to be a mask applied, >>>>>>>> but I have no idea where is it coming from. Both client machines >>>>>>>> are Windows 7 - I just can't figure out the reason. It used to >>>>>>>> work fine before the Samba upgrade. The wrong acl's for the .ldb >>>>>>>> file look like this: >>>>>>>> >>>>>>>> # file: praxis_be.ldb >>>>>>>> # owner: HEBI\\user1 >>>>>>>> # group: HEBI\\domain\040users >>>>>>>> user::rw- >>>>>>>> user:root:rwx??????????? #effective:r-- >>>>>>>> group::rwx??????????? #effective:r-- >>>>>>>> group:HEBI\\domain\040users:rwx??? #effective:r-- >>>>>>>> group:HEBI\\domain\040computers:r-x??? #effective:r-- >>>>>>>> mask::r-- >>>>>>>> other::--- >>>>>>>> >>>>>>>> >>>>>>>> What I've tried: >>>>>>>> >>>>>>>> 1. I have set and reset the acl's on the Linux side for the >>>>>>>> share and parent dir (the lock file is in the root of the >>>>>>>> network share) - and made sure it doesn't have a mask: >>>>>>> >>>>>>> You should stop doing this, as it is a DC, you need to set the >>>>>>> permissions from Windows, see here: >>>>>>> >>>>>>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs >>>>>>> >>>>>> >>>>>> Thank you for the quick answer. I should have mentioned that I >>>>>> tried that as well. Could you confirm if "inherit acls" and >>>>>> "create mask" and "directory mask" should still apply to Samba in >>>>>> AD mode any more - or not? >>>>>> >>>>>> >>>>> Your share on the DC should only be this: >>>>> >>>>> [praxis] >>>>> path = /srv/samba/praxis >>>>> read only = No >>>>> >>>>> You shouldn't add anything else, it has always been this way on a DC. >>>> >>>> Yes - that's what I read in the docs - and that's what I started >>>> with. But that's when I don't get the expected ACL inheritance. I >>>> just trimmed the share definition down again to the above, and when >>>> I created a dir, the mask kicks in again: >>>> >>>> # file: test3 >>>> # owner: root >>>> # group: HEBI\\domain\040users >>>> # flags: -s- >>>> user::rwx >>>> user:root:rwx??????????? #effective:r-x >>>> user:3000017:r-x >>>> group::rwx??????????? #effective:r-x >>>> group:HEBI\\domain\040users:rwx??? #effective:r-x >>>> group:HEBI\\domain\040computers:r-x >>>> mask::r-x >>>> other::--- >>>> default:user::rwx >>>> default:user:root:rwx >>>> default:user:3000017:r-x >>>> default:group::rwx >>>> default:group:HEBI\\domain\040users:rwx >>>> default:group:HEBI\\domain\040computers:r-x >>>> default:mask::rwx >>>> default:other::--- >>>> >>>> >>>> Is the mask coming from the local Linux filesystem umask? If yes, >>>> shouldn't the ACL's supersede it? >>>> >>>>> I think it might help if you posted the global part of the smb.conf >>>> >>>> Sure: >>>> >>>> >>>> [global] >>>> bind interfaces only = Yes >>>> interfaces = lo eth1 tun0 tun1 >>>> netbios name = HEBI-SERVER >>>> realm = HEBI.LAN >>>> server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, >>>> winbindd, ntp_signd, kcc, dnsupdate >>>> workgroup = HEBI >>>> server role = active directory domain controller >>>> idmap_ldb:use rfc2307 = yes >>>> comment >>>> >>>> log file = /var/log/samba/%m.log >>>> max log size = 1000 >>>> >>>> mangling method = hash2 >>>> mangle prefix = 6 >>>> reset on zero vc = yes >>>> deadtime = 10 >>>> >>>> >>>> load printers = yes >>>> rpc_server:spoolss = external >>>> rpc_daemon:spoolssd = fork >>>> >>> Would it help if I told you that you are reading the wrong permissions ? >> >> That kind of helps, in the sense that I never realised that there are >> two sets of ACL's stored in two different places. I have just re-read >> for the n-th time the >> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs >> and I'm still trying to get my head around it. I guess that means the >> real permissions (seen on the Windows side) are made up of Linux ACL's >> *plus* the extended attributes stored by Samba elsewhere? >> >> Also, it doesn't quite solve the problem, as the "Domain Users" still >> gets no permissions whatsoever when creating new dirs, in spite of the >> fact that the parent dir has full permissions for "Domain Users" (on >> the Windows side). > > Ok - I might have at least a partial answer. Somehow the default mask in > Samba still seems to be obeyed - even in AD mode. It seems to lack by > default the 'write' bit - which gets removed from the permissions when > creating a new directory. Without any additional share settings in > smb.conf, a new subdirectory gets created with the following two sets of > permissions, no matter what I try: > > "Domain users" - Traverse, Read attributes, Read extended attributes - > This folder only > "Domain users" - Full Control - Subfolders and files only > > If I add the following settings in smb.conf for the share: > > create mask = 0660 > directory mask = 0770 > > Then finally the Windows permissions for a new subdirectory are as > expected - just one set for "Domain Users": > > "Domain Users" - Full Control - This folder, subfolders and files > > It seems the the Samba default umask limits the ACL permissions it > grants on the Windows side to new files and folders. Could this be a bug > - as it doesn't seem to be mentioned anywhere in the docs?Can anybody confirm if they have seen this behaviour with a Samba AD DC with file sharing - where the default smb.conf umask setting (unset in smb.conf) limits group ACL's assigned to subfolders - and doesn't grant group write privilege - although it should?
Maybe Matching Threads
- Problems with inconsistent ACL inheritance and permissions after Samba upgrade
- Problems with inconsistent ACL inheritance and permissions after Samba upgrade
- Problems with inconsistent ACL inheritance and permissions after Samba upgrade
- Problems with inconsistent ACL inheritance and permissions after Samba upgrade
- Problems with inconsistent ACL inheritance and permissions after Samba upgrade