Univention Bugzilla – Bug 45372
Wrong directory permission 0o770 /etc/univention/ssl/$backup - 00_checks.81_diagnostic_checks regularly fails for backup
Last modified: 2019-12-13 12:35:45 CET
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/
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)
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.
Most often backup092, but also backup093, so not S4 related.
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.