Univention Bugzilla – Bug 21529
Berechtigungen setzen beim Anlegen von Festplatten-Images
Last modified: 2023-06-28 10:46:30 CEST
Die Festplatten-Images werden immer mit den Berechtigungen 0700 angelegt. Das ist in manchen Umgebungen eventuell nicht gewünscht, beispielsweise wenn die kvm Prozesse mit besonderem Benutzer/Gruppe gestartet werden.
Es können jetzt die UCR-Variablen uvmm/volume/permissions/(mode|owner|group) gesetzt werden um die Brechtigungen zu beeinflussen. ChangeLog-Eintrag wurde hinzugefügt
Das funktionierte in meinen Tests nicht, weder auf Xen noch unter KVM: root@xenslave:/var/lib/libvirt/images# ucr search volume uvmm/volume/permissions/group: Domain Users Defines the group for new hard drive images that are created in a storage pool uvmm/volume/permissions/mode: 444 Defines the file mode permissions for new hard drive images that are created in a storage pool uvmm/volume/permissions/owner: jmm Defines the owner for new hard drive images that are created in a storage pool root@xenslave:/var/lib/libvirt/images# ls -lha insgesamt 8,0K drwxr-xr-x 2 root root 4,0K 14. Mär 15:22 . drwxr-xr-x 5 root root 4,0K 14. Mär 07:59 .. -rw------- 1 root root 20G 11. Mär 09:48 ucs24-02-0.raw -rw------- 1 root root 20G 14. Mär 15:17 ucs24-04-0.raw -rw------- 1 root root 20G 14. Mär 15:19 ucs24-05-0.raw -rw------- 1 root root 20G 14. Mär 15:22 ucs24-06-0.raw -rw------- 1 root root 20G 11. Mär 09:47 ucs24-foo-0.raw -rw------- 1 root root 20G 10. Mär 15:08 ucs24-guppi-0.raw root@kvm:/var/lib/libvirt/images# ls -lha insgesamt 2,4G drwxr-xr-x 2 root root 4,0K 14. Mär 15:17 . drwxr-xr-x 5 root root 4,0K 14. Mär 09:00 .. lrwxrwxrwx 1 root root 18 14. Mär 15:00 lfödlfödlfd -> /tmp/lfödlfödlfd -rw------- 1 libvirt-qemu kvm 1,2G 14. Mär 15:26 ucs24-01-0.qcow2 -rw------- 1 root root 256K 14. Mär 13:26 ucs24-02-0.qcow2 -rw------- 1 root root 256K 14. Mär 15:17 ucs24-03-0.qcow2 -rw------- 1 root root 1,3G 14. Mär 14:42 ucs24-64-20 (Neu)-0.qcow2 -rw------- 1 root root 256K 14. Mär 13:33 w2k8-03-0.qcow2 Der Changelog-Eintrag sollte auch überarbeitet werden, statt "können jetzt per UCR-Variablen gesetzt werden" sollten dort auch die Variablen aufgeführt werden.
Bei mir hat das funktioniert. Allerdings sind ein paar Dinge zu beachten, die ich in der Doku noch einmal hervorgehoben habe: - owner und group als numerische ID - permissions sind Oktal (führende 0 ist nicht notwendig) - uvmmd muss neu gestartet werden ChangeLog-Eintrag ist angepasst
Ändere ich die Berechtigungen, werden die Image-Dateien zwar korrekt angelegt, das Starten einer erzeugten VM schlägt dann aber fehl, was die Berechtigungen wieder zurücksetzt: root@kvm:/var/lib/libvirt/images# ucr search --brief volume uvmm/volume/permissions/group: 5001 uvmm/volume/permissions/mode: 444 uvmm/volume/permissions/owner: 2005 Die Berechtigungen nach dem Anlegen: root@kvm:/var/lib/libvirt/images# ls -lha ucs24-24-0.qcow2 -r--r--r-- 1 jmm Domain Users 193K 24. Mär 09:49 ucs24-24-0.qcow2 Die Berechtigungen nach dem Start der VM: root@kvm:/var/lib/libvirt/images# ls -lha ucs24-24-0.qcow2 -r--r--r-- 1 root root 193K 24. Mär 09:49 ucs24-24-0.qcow2 Folgender Fehler wird in die daemon-errors geloggt: libvir: QEMU error : Domain not found: no domain with matching name 'ucs24-23' libvir: Storage error : Storage volume not found: no storage vol with matching path libvir: Storage error : Storage volume not found: no storage vol with matching name 'ucs24-23-0.qcow2' libvir: QEMU error : internal error process exited while connecting to monitor: kvm.bin: -drive file=/var/lib/libvirt/images/ucs24-23-0.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: could not open disk image /var/lib/libvirt/images/ucs24-23-0.qcow2: Permission denied
(In reply to comment #4) > Ändere ich die Berechtigungen, werden die Image-Dateien zwar korrekt angelegt, > das Starten einer erzeugten VM schlägt dann aber fehl, was die Berechtigungen > wieder zurücksetzt: > > root@kvm:/var/lib/libvirt/images# ucr search --brief volume > uvmm/volume/permissions/group: 5001 > uvmm/volume/permissions/mode: 444 > uvmm/volume/permissions/owner: 2005 > > Die Berechtigungen nach dem Anlegen: > > root@kvm:/var/lib/libvirt/images# ls -lha ucs24-24-0.qcow2 > -r--r--r-- 1 jmm Domain Users 193K 24. Mär 09:49 ucs24-24-0.qcow2 > > Die Berechtigungen nach dem Start der VM: > > root@kvm:/var/lib/libvirt/images# ls -lha ucs24-24-0.qcow2 > -r--r--r-- 1 root root 193K 24. Mär 09:49 ucs24-24-0.qcow2 Das liegt daran, dass die Berechtigungen entsprechen des kvm-Prozessbesitzers geändert werden > Folgender Fehler wird in die daemon-errors geloggt: > > libvir: QEMU error : Domain not found: no domain with matching name 'ucs24-23' > libvir: Storage error : Storage volume not found: no storage vol with matching > path > libvir: Storage error : Storage volume not found: no storage vol with matching > name 'ucs24-23-0.qcow2' > libvir: QEMU error : internal error process exited while connecting to monitor: > kvm.bin: -drive > file=/var/lib/libvirt/images/ucs24-23-0.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: > could not open disk image /var/lib/libvirt/images/ucs24-23-0.qcow2: Permission > denied Das ist ein anderes Images. Ist das eine Ableitung? Oder gehört die Fehlermeldung woanders zu? Wenn die Berechtigung des abgeleiteten Image nicht mit dem Master übereinstimmen kommt es zu solchen Fehlern. Auch wenn der kvm-Prozessbestizer auf eines der Images nicht zugreifen kann.
Ich habe den Changelog Eintrag zunächst wieder entfernt. Es sollte nochmal geprüft werden, was genau das Ziel ist.
(In reply to comment #6) > Ich habe den Changelog Eintrag zunächst wieder entfernt. Es sollte nochmal > geprüft werden, was genau das Ziel ist. Das wird beispielsweise bei unserer Testumgebung eingesetzt, damit alle Nutzer auf die Instanzen zugreifen können. Dafür gehören die Master Images einer Gruppe X. Abgeleiteten Images müssen entsprechende Berechtigungen haben (auch der Gruppe X gehören), damit die Instanzen gestartet werden können.
(In reply to comment #7) > (In reply to comment #6) > > Ich habe den Changelog Eintrag zunächst wieder entfernt. Es sollte nochmal > > geprüft werden, was genau das Ziel ist. > > Das wird beispielsweise bei unserer Testumgebung eingesetzt, damit alle Nutzer > auf die Instanzen zugreifen können. Dafür gehören die Master Images einer > Gruppe X. Abgeleiteten Images müssen entsprechende Berechtigungen haben (auch > der Gruppe X gehören), damit die Instanzen gestartet werden können. Aber wenn die Benutzer per UMC darauf zugreifen, dann sind sie root und per sudo virsh geht es auch direkt. Gibt es noch mehr Vorteile?
(In reply to comment #8) > Aber wenn die Benutzer per UMC darauf zugreifen, dann sind sie root und per > sudo virsh geht es auch direkt. Gibt es noch mehr Vorteile? Dabei werden die Maschinen aber nicht als root gestartet sondern normalerweise als libvirt-qemu:kvm. Der Benutzer könnte dann aber nicht auf die Master-Images zugreifen. Es kann gut sein, dass das ausschließlich ein Problem hier bei uns ist wo Benutzer auf der Console auf die Dateien der Master-Images zugreifen können müssen.
Vermutlich passt an dieser Stelle noch folgendes Phänomen, welches in der Testumgebung augfgetreten ist: Aus irgendwelchen Gründen wurde im Laufe des Vormittages die Berechtigung auf ein Floppyimage auf Omar angepasst, so dass die Domäne keinen Schreibzugriff mehr hatte und Instanzen mit diesem Floppyimage auf Dacke und Odda nicht mehr gestartet werden konnten (permission denied). Es steht zu vermuten, dass dort irgendwas von UVMM initiert wurde, da das Floppyimage morgens noch erfolgreich auf Dacke verwendet werden konnte.
This issue has been filed against UCS 2.4. UCS 2.4 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug". In this case please provide detailed information on how this issue is affecting you.