Univention Bugzilla – Bug 31272
turn off periodic fACLs reset for "Authenticated Users" (sysvol-sync)
Last modified: 2013-06-07 21:38:43 CEST
+++ This bug was initially created as a clone of Bug #31271 +++ Currently the sysvol-sync script calls setfacl on each run, to (re-)set default read permissions for the group "Authenticated Users". We should make this configurable via UCR, so we can avoid this if necessary, e.g. in the UCS@school context. Why should we want this? This is required in the following situation: For some group policy restrictions currently planned for the exam mode of UCS@school it is important narrow down the security filter of a Group Policy Container to a specific group (see Bug 30834 Comment 2). In this case the school administrator will manually remove the default read permission for the group "Authenticated Users" ("AU" for short) for the specific GPO. The Microsoft Group Policy Manamgenent Console (GPMC) correctly sets the according directory ACLs (nTSecurityDescriptor) on the Group Policy Container in the Samba/Active Directory and writes the corresponding NTACLs in the associated GPO subdirectory beneath the sysvol Policies folder. All fine up to this point. Then a bit later, the sysvol-sync script modifies the filesystem fACLs. Now, if an Administrator starts the GPMC again, the tool complains that the permissions in the sysvol folder are not consistent. This probably is because Samba translates the adjusted fACL of the GPO into an NTACL which shows read permissions for "AU", which does not agree with the nTSecurityDescriptor of the corresponding Group Policy Container in the Samba/Active Directory. Now the Administrator can click "OK" in the tool to fix this, but after the next sysvol-sync run it happens again. We should avoid that. Why did we set fACLs for "Authenticated Users" in the first place anyway? We did this for two reasons: 1. sysvol access for normal users. This used to be an issue with Samba4 Alpha17 in UCS 3.0 and seems to be reolved now due to the new "s3fs" integration of smbd and the Samba authentication backend. In my tests this was not an issue any more (in UCS 3.1-1), but it certainly should be checked again for this bug (also with UCS 3.1-0). 2. The sysvol-sync script copies the sysvol directories from other Samba4-DCs with machine credentials. Allowing "Authenticated Users" made this possible. So we need a replacement for this. But it looks like there is a generic solution for this: GPOs created with the GPMC have read permissions for "Enterprise Domain Controllers", which is a well-known group. Due to Bug 29000 this currently ends up e.g. as unmapped Posix-ID 3000009 in the GPO fACLs on UCS@school Samba4 Slave DCs. Thus, if we don't continue to tattoo the default fACLs for "AU", we should fix Bug 29000 at least for the Enterprise DCs group.
We should use the new UCR variable to disable this behaviour on UCS@school Samba4 DCs. Probably we can set it in the packages generated by ucs-school-metapackage.
The postinst scripts in ucs-school-metapackage now set samba4/sysvol/sync/setfacl/AU?false. Changelog adjusted.
Are there any side effects that may be possible?
It seems to work as expected: > root@slave47:~# ls -l /var/lib/samba/sysvol/ucsschool.dev/Policies/ > total 20 > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {31B2F340-016D-11D2-945F-00C04FB984F9} > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {6AC1786C-016F-11D2-945F-00C04FB984F9} > drwxr-x---+ 2 root root 4096 May 29 06:57 foobar > > root@slave47:~# setfacl -d -b /var/lib/samba/sysvol/ucsschool.dev/Policies/foobar > root@slave47:~# ls -l /var/lib/samba/sysvol/ucsschool.dev/Policies/ > total 20 > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {31B2F340-016D-11D2-945F-00C04FB984F9} > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {6AC1786C-016F-11D2-945F-00C04FB984F9} > drwx------ 2 root root 4096 May 29 06:57 foobar > > root@slave47:~# /usr/share/univention-samba4/scripts/sysvol-sync.sh > root@slave47:~# ls -l /var/lib/samba/sysvol/ucsschool.dev/Policies/ > total 20 > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {31B2F340-016D-11D2-945F-00C04FB984F9} > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {6AC1786C-016F-11D2-945F-00C04FB984F9} > drwx------ 2 root root 4096 May 29 06:57 foobar The corresponding UCRV samba4/sysvol/sync/setfacl/AU is set to false and the ACLs of the newly created directory foobar are not reset. Changes → OK Changelog → OK → VERIFIED
It seems that after some time the ACLs a reset again: > root@slave47:~# ls -l /var/lib/samba/sysvol/ucsschool.dev/Policies/ > total 28 > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {31B2F340-016D-11D2-945F-00C04FB984F9} > drwxrwx---+ 4 Administrator Domain Admins 4096 May 29 05:49 {6AC1786C-016F-11D2-945F-00C04FB984F9} > drwxr-x---+ 2 root root 4096 May 29 06:57 foobar > drwxr-x---+ 2 root root 4096 May 29 07:40 foobar2 > drwxr-x---+ 2 root root 4096 May 29 08:05 foobar3
Cannot reproduce this with the latest packages, see /var/lib/samba/sysvol/ucsschool.dev/Policies/foobar4: root@slave47:~# getfacl /var/lib/samba/sysvol/ucsschool.dev/Policies/foobar4getfacl: Removing leading '/' from absolute path names # file: var/lib/samba/sysvol/ucsschool.dev/Policies/foobar4 # owner: root # group: root user::rwx group::---
(In reply to comment #6) > Cannot reproduce this with the latest packages, see > /var/lib/samba/sysvol/ucsschool.dev/Policies/foobar4: > > > root@slave47:~# getfacl > /var/lib/samba/sysvol/ucsschool.dev/Policies/foobar4getfacl: Removing leading > '/' from absolute path names > # file: var/lib/samba/sysvol/ucsschool.dev/Policies/foobar4 > # owner: root > # group: root > user::rwx > group::--- Yes, it seems that the latest packages were not installed on the master. Now it looks good. → VERIFIED
UCS@school 3.1 R2 has been released: http://download.univention.de/doc/release-notes-ucsschool-3.1-rev2.pdf If this error occurs again, please use "Clone This Bug".