Description of problem: When creating an LVM snapshot, the original volume's ownership + permissions are reset to | brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 This is very bad because e.g. libvirt changes ownership to qemu:qemu and assigns system_u:object_r:svirt_image_t SELinux attributes when starting a guest. When backing up the guest by creating a snapshot, the guest can not access the volume anymore. E.g. # ll -Z /dev/vg01/data /dev/dm-17 | cat brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0 /dev/dm-17 lrwxrwxrwx. root root system_u:object_r:device_t:s0 /dev/vg01/data -> ../dm-17 # lvcreate -L 1G -s /dev/vg01/data # ll -Z /dev/vg01/data /dev/dm-17 | cat brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-17 lrwxrwxrwx. root root system_u:object_r:device_t:s0 /dev/vg01/data -> ../dm-17 Version-Release number of selected component (if applicable): lvm2-2.02.61-1.fc13.x86_64 udisks-1.0.1-1.fc13.x86_64 udev-151-9.fc13.x86_64 How reproducible: 100%
(In reply to comment #0) > This is very bad because e.g. libvirt changes ownership to qemu:qemu and > assigns system_u:object_r:svirt_image_t SELinux attributes when starting The nodes are managed by udev, so udev daemon will overwrite any permissions defined and set before by any other means other than udev rules themselves. By default, it is that root:disk for block devices. Please, use the 12-dm-permissions.rules template file to define custom permissions for dm/lvm devices (you can find it in /usr/share/doc/device-mapper-<version> directory). It contains a few examples and hints on how to set the rules. Then place the file in /etc/udev/rules.d directory for the udev daemon to interpret it.
..anyway, libvirt should be aware of udev and it should not change or redefine permissions in such a way. If they really do, then a bug must be filed for libvirt team as well.
ok; reassing to libvirt then... libvirt changes ownership + SELinux attributes of LVM volumes and the changed behavior of lvm/kernel/udev/... in F13 breaks this.
fwiw, in pre F13 (F11 + F12) the LVM volume devices are created twice: once as /dev/dm-* and in /dev/mapper/. Creating snapshots had the same effects on the /dev/dm-* inodes but /dev/mapper was not touched. Because the /dev/mapper/... paths are given to qemu, the problem was not visible in F11/F12. Now, in F13, /dev/mapper/* entries are symlinks to /dev/dm-* and qemu sees the bad permissions.
(In reply to comment #4) > fwiw, in pre F13 (F11 + F12) the LVM volume devices are created twice: once as > /dev/dm-* and in /dev/mapper/. Yes, we added official udev support for device-mapper/LVM2 in F-13 only. In previous versions, the /dev/mapper content was created statically by libdevmapper itself. The /dev/dm-X nodes were always created by udev - there's no way for udev to stop creating nodes, so this is udev's default. > Now, in F13, /dev/mapper/* entries are symlinks to /dev/dm-* and qemu sees the > bad permissions. Yes, now, we use those symlinks in /dev/mapper with /dev/dm-X target (the same applies for /dev/<vgname>). That's a standard required by udev team.
still with libvirt-0.8.2-1.fc13.x86_64
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Can anyone still reproduce on a newer fedora? If so please reopen, until then closing.