Univention Bugzilla – Bug 21587
Join mit angepasster umask
Last modified: 2012-03-04 14:34:21 CET
Wenn die umask per UCR geändert ist, dann scheinen nicht alle Verzeichnisse die richtige Berechtigung zu haben. Auf einem Kundensystem: # ucr search umask umask: 027 Dort funktionierte die UMC Anmeldung erst nach: chmod o+rx /etc/univention/ssl/ chmod o+rx /etc/univention/ssl/ucsCA/
Scheint unter UCS 3.0 und 2.4-1 nicht mehr reproduzierbar zu sein.
Auch unter 2.4-3 und 2.4-4 nicht reproduzierbar.
Mit 3.0-0 konnte ich das Problem nachstellen. -> ucr get umask 0027 -> umask 0027 -> join -> ls -al /etc/univention/ssl insgesamt 32 drwxr-x--- 6 root DC Backup Hosts 4096 9. Nov 16:40 . bzw. -> ucr get umask -> umask 0022 -> ls -al /etc/univention/ssl insgesamt 20 drwxr-xr-x 5 root DC Backup Hosts 4096 9. Nov 16:27 .
Created attachment 4096 [details] fix join fail with modified umask Der patch modifiert management/univention-join/univention-join so, dass zu Beginn des scripts die aktuelle umask in der Variable UMASK gespeichert wird. Anschließend wird die umask vorrübergehend auf den Wert "0022" gesetzt. Am Ende der Durchführung wird die umask wieder auf den in UMASK gespeicherten Wert zurückgesetzt.
(In reply to comment #4) > Created an attachment (id=4096) [details] > fix join fail with modified umask > > Der patch modifiert management/univention-join/univention-join so, dass zu > Beginn des scripts die aktuelle umask in der Variable UMASK gespeichert wird. > Anschließend wird die umask vorrübergehend auf den Wert "0022" gesetzt. Am Ende > der Durchführung wird die umask wieder auf den in UMASK gespeicherten Wert > zurückgesetzt. Besser so lösen, dass für die Verzeichnisse / Dateien, die andere Rechte benötigen diese direkt gesetzt werden. Die umask wurde ja absichtlich so angepasst, ansonsten verhalten sich die Dienste anders, wenn die vom Join-Prozess gestartet wurden.
*** Bug 16327 has been marked as a duplicate of this bug. ***
Created attachment 4097 [details] fix join fail with modified umask Pass univention-join so an, dass die Rechte für /etc/univention/ssl, /etc/univention/ssl/ucsCA und /etc/univention/ssl/ucsCA/CAcert.pem während des Joinvorgangs auch dann stimmen, wenn die umask zuvor durch den User geändert worden ist.
(In reply to comment #7) > Created an attachment (id=4097) [details] > fix join fail with modified umask > > Pass univention-join so an, dass die Rechte für /etc/univention/ssl, > /etc/univention/ssl/ucsCA und /etc/univention/ssl/ucsCA/CAcert.pem während des > Joinvorgangs auch dann stimmen, wenn die umask zuvor durch den User geändert > worden ist. OK, den Patch bitte übernehmen ins SVN und vor die chmod-Zeilen einen kleinen Kommentar hinzufügen warum dies geschieht zusammen mit einem Verweis auf Bug #21587.
Der Patch wurde übernommen und das Paket gebaut. univention-join (4.0.30-1) unstable; urgency=low * prevent join from failing if umask is modified (Bug #21587)
Das gilt jetzt aber nur für "domaincontroller_backup". Bei einem Slave etc. wird das chmod gar nicht ausgeführt. if [ "$server_role" = "domaincontroller_backup" ]; then ... chmod ... ... elif [ "$server_role" = "domaincontroller_slave" ]; then ... elif [ "$server_role" = "memberserver" ]; then ... ... Also entweder das chmod in jeden der if/elif Zweige rein oder irgendwie am Ende, wenn das Verzeichnis existiert die Berechtigungen anpassen.
Änderungsvorschlag übernommen. Paket gebaut. univention-join (4.0.32-1) unstable; urgency=low * fix for Bug #21587 now pertains all system roles (Bug #21587)
ok, mit (max.) 027 als umask funktioniert es, alles was noch restriktiver ist (777, 077) funktioniert nicht (aber das ist ok) Changelog Eintrag vorhanden.
UCS 3.0-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"