Bug 31272 - turn off periodic fACLs reset for "Authenticated Users" (sysvol-sync)
turn off periodic fACLs reset for "Authenticated Users" (sysvol-sync)
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: Samba 4
UCS@school 3.1
Other Linux
: P5 normal (vote)
: UCS@school 3.1 R2
Assigned To: Arvid Requate
Alexander Kläser
: interim-2
Depends on: 31271 31275
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-02 17:55 CEST by Arvid Requate
Modified: 2013-06-07 21:38 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2013-05-02 17:55:57 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.
Comment 1 Arvid Requate univentionstaff 2013-05-02 18:01:13 CEST
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.
Comment 2 Arvid Requate univentionstaff 2013-05-23 23:48:20 CEST
The postinst scripts in ucs-school-metapackage  now set samba4/sysvol/sync/setfacl/AU?false.

Changelog adjusted.
Comment 3 Alexander Kläser univentionstaff 2013-05-28 15:44:15 CEST
Are there any side effects that may be possible?
Comment 4 Alexander Kläser univentionstaff 2013-05-29 14:25:42 CEST
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
Comment 5 Alexander Kläser univentionstaff 2013-05-29 15:05:54 CEST
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
Comment 6 Arvid Requate univentionstaff 2013-05-29 16:54:59 CEST
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::---
Comment 7 Alexander Kläser univentionstaff 2013-05-29 17:01:56 CEST
(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
Comment 8 Sönke Schwardt-Krummrich univentionstaff 2013-06-07 21:38:43 CEST
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".