Bug 31275 - sysvol-sync re-sets read fACLs for "Authenticated Users", make this configurable via UCR
sysvol-sync re-sets read fACLs for "Authenticated Users", make this configura...
Product: UCS
Classification: Unclassified
Component: Samba4
UCS 3.1
Other Linux
: P5 normal (vote)
: UCS 3.2
Assigned To: Arvid Requate
Stefan Gohmann
: interim-1
Depends on: 31271
Blocks: 31272
  Show dependency treegraph
Reported: 2013-05-03 06:09 CEST by Stefan Gohmann
Modified: 2013-11-19 06:44 CET (History)
1 user (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:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2013-05-03 06:09:46 CEST
I think with UCS 3.2 we should change the default so that the (re-)set is not executed. 

+++ 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

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

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-07-16 15:50:01 CEST
univention-samba4 now sets samba4/sysvol/sync/setfacl/AU?'false'.
Changelog adjusted.
Comment 2 Stefan Gohmann univentionstaff 2013-08-14 15:44:32 CEST
OK default switched to false.

Changelog: OK
Comment 3 Stefan Gohmann univentionstaff 2013-11-19 06:44:18 CET
UCS 3.2 has been released:

If this error occurs again, please use "Clone This Bug".