Bug 45372 - Wrong directory permission 0o770 /etc/univention/ssl/$backup - 00_checks.81_diagnostic_checks regularly fails for backup
Wrong directory permission 0o770 /etc/univention/ssl/$backup - 00_checks.81_d...
Status: NEW
Product: UCS
Classification: Unclassified
Component: Join (univention-join)
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-09 07:55 CEST by Stefan Gohmann
Modified: 2019-12-13 12:35 CET (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.103
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 Stefan Gohmann univentionstaff 2017-09-09 07:55:09 CEST
The diagnostic module shows that the SSL directory of the backup has the wrong permissions in EC2 setups:
[2017-09-09 00:22:56.235466] E     Exception: ###############
[2017-09-09 00:22:56.235540] E     Überprüfe Datei Berechtigungen
[2017-09-09 00:22:56.235617] E     Datei '/etc/univention/ssl/backup092.autotest092.local' hat Datei-Modus 770, 750 war erwartet.###############
[2017-09-09 00:22:56.235663] 
[2017-09-09 00:22:56.235754] 81_diagnostic_checks.py:24: Exception

That happens only on DC backups:
http://jenkins.knut.univention.de:8080/job/UCS-4.2/job/UCS-4.2-2/job/AutotestJoin/8/SambaVersion=s3,Systemrolle=backup/testReport/00_checks/81_diagnostic_checks/test/
Comment 2 Philipp Hahn univentionstaff 2019-09-02 12:12:50 CEST
Still applies to UCS-4.4, where this test is the only failing one for Backup-w/o-samba for 12 runts:
<http://jenkins.knut.univention.de:8080/job/UCS-4.4/job/UCS-4.4-1/job/AutotestJoin/55/SambaVersion=no-samba,Systemrolle=backup/testReport/00_checks/81_diagnostic_checks/backup092/>

And the culprit is:

management/univention-join/20univention-join.inst:110
  »···test -d "/etc/univention/ssl/$hostname" && chgrp -R "DC Backup Hosts" "/etc/univention/ssl/$hostname" && chmod g+rwx "/etc/univention/ssl/$hostname" && find "/etc/univention/ssl/$hostname/" -type f | xargs chmod g+rw

It gets fixed as soon as the `rsync /etc/univention/ssl/` cron jobs runs as the permission is only wrong on the backup, but correct on the master.
Looking at the code slaves should also be affected...


# tail -n2 /etc/audit/rules.d/audit.rules 
-a always,exit -F path=/etc/univention/ssl/backup -F perm=wa
-a always,exit -F path=/etc/univention/ssl/backup.phahn.dev -F perm=wa

# ausearch -f /etc/univention/ssl -i
----
type=PROCTITLE msg=audit(09/02/2019 11:46:17.376:70) : proctitle=chgrp -R DC Backup Hosts /etc/univention/ssl/backup 
type=PATH msg=audit(09/02/2019 11:46:17.376:70) : item=0 name=/etc/univention/ssl/backup inode=526412 dev=fd:00 mode=link,777 ouid=root ogid=nogroup rdev=00:00 nametype=NORMAL 
type=CWD msg=audit(09/02/2019 11:46:17.376:70) : cwd=/etc/univention/ssl_1909021138 
type=SYSCALL msg=audit(09/02/2019 11:46:17.376:70) : arch=x86_64 syscall=fchownat success=yes exit=0 a0=0xffffff9c a1=0x560a521aec90 a2=0xffffffff a3=0x138d items=1 ppid=14791 pid=14826 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=chgrp exe=/bin/chgrp key=(null) 
----
type=PROCTITLE msg=audit(09/02/2019 11:46:17.376:71) : proctitle=chmod g+rwx /etc/univention/ssl/backup 
type=PATH msg=audit(09/02/2019 11:46:17.376:71) : item=0 name=/etc/univention/ssl/backup inode=526435 dev=fd:00 mode=dir,750 ouid=backup$ ogid=DC Backup Hosts rdev=00:00 nametype=NORMAL 
type=CWD msg=audit(09/02/2019 11:46:17.376:71) : cwd=/etc/univention/ssl_1909021138 
type=SYSCALL msg=audit(09/02/2019 11:46:17.376:71) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xffffffffffffff9c a1=0x563f6c63a0f0 a2=0770 a3=0x3c0 items=1 ppid=14791 pid=14827 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=chmod exe=/bin/chmod key=(null) 
----
type=PROCTITLE msg=audit(09/02/2019 12:00:05.008:122) : proctitle=rsync -e ssh -o StrictHostKeyChecking=no -o ControlPath=none -az --delete backup$@m34.phahn.dev:/etc/univention/ssl/ /etc/univen 
type=PATH msg=audit(09/02/2019 12:00:05.008:122) : item=0 name=backup inode=526412 dev=fd:00 mode=link,777 ouid=root ogid=DC Backup Hosts rdev=00:00 nametype=NORMAL 
type=CWD msg=audit(09/02/2019 12:00:05.008:122) : cwd=/etc/univention/ssl 
type=SYSCALL msg=audit(09/02/2019 12:00:05.008:122) : arch=x86_64 syscall=lchown success=yes exit=0 a0=0x7ffddb089dd0 a1=0x0 a2=0xfffe a3=0x0 items=1 ppid=16814 pid=16815 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rsync exe=/usr/bin/rsync key=(null) 
----
type=PROCTITLE msg=audit(09/02/2019 12:00:05.008:123) : proctitle=rsync -e ssh -o StrictHostKeyChecking=no -o ControlPath=none -az --delete backup$@m34.phahn.dev:/etc/univention/ssl/ /etc/univen 
type=PATH msg=audit(09/02/2019 12:00:05.008:123) : item=0 name=backup.phahn.dev inode=526435 dev=fd:00 mode=dir,770 ouid=backup$ ogid=DC Backup Hosts rdev=00:00 nametype=NORMAL 
type=CWD msg=audit(09/02/2019 12:00:05.008:123) : cwd=/etc/univention/ssl 
type=SYSCALL msg=audit(09/02/2019 12:00:05.008:123) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x7ffddb089dd0 a1=0750 a2=0x1519c684 a3=0x0 items=1 ppid=16814 pid=16815 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rsync exe=/usr/bin/rsync key=(null)
Comment 3 Philipp Hahn univentionstaff 2019-09-03 11:08:08 CEST
This is a lot more complicated as multiple scripts use different permissions and the final permission depend on which script was last used:
 base/univention-ssl/make-certificates.sh
 base/univention-ssl/debian/univention-ssl.postinst
 base/univention-ssl/ssl-sync
 base/univention-ssl/gencertificate.py
 base/univention-system-setup/usr/lib/univention-system-setup/scripts/setup-join.sh
 base/univention-system-setup/usr/lib/univention-system-setup/scripts/10_basis/10hostname
 base/univention-system-setup/usr/lib/univention-system-setup/scripts/10_basis/12domainname
 base/univention-system-setup/usr/lib/univention-system-setup/scripts/40_ssl/10ssl
 management/univention-join/univention-join
 management/univention-join/20univention-join.inst
 management/univention-join/debian/univention-join.postinst

Some of those scripts even set different permission in consecutive lines.

And the permissions depend on the system beging joined: group "DC Backup Hosts" only is known after that.

I started documenting the target state, but this is still WIP and needs to be discussed more:
<https://hutten.knut.univention.de/mediawiki/index.php/Zertifikat_Debugging#Berechtigungen>

Also be aware of Bug #49036, which adds additional issues.
Comment 4 Philipp Hahn univentionstaff 2019-10-28 08:49:21 CET
Most often backup092, but also backup093, so not S4 related.
Comment 5 Florian Best univentionstaff 2019-12-13 12:35:45 CET
The test case passes now. We could close this Bug as duplicate of Bug #49036 except that we should investigate if any of the files in comment 3 is still relevant/unfixed.