Hide Forgot
This is more a wishlist bug, than a real bug report. I'm running vdsm directly from my target directory, without any init script and without the udev rules (I guess they could fix this, but there's another way I want to explain) on Debian. (Some things in here may be Debian specific) When I add an iSCSI storage domain vdsm creates the lvm on it and changes the rights for every device it creates so it can write on it. But this only happens, when the the storage gets added. After a reboot of the system those rights are lost. There're a few solutions here to fix this in a clean way: Either adding vdsm in the disk group (a group with read-write permissions to block devices) or changing the rights when the storage goes up. I prefer the later method, because otherwise vdsm would have permissions to access the device with the system on it and if somebody finds a bug in vdsm, it would be easy for him to compromise the whole system. I haven't found the part in the source yet, where to change this, otherwise I'd provided a patch.
(In reply to comment #0) > This is more a wishlist bug, than a real bug report. > > I'm running vdsm directly from my target directory, without any init script and > without the udev rules (I guess they could fix this, but there's another way I > want to explain) on Debian. (Some things in here may be Debian specific) > > When I add an iSCSI storage domain vdsm creates the lvm on it and changes the > rights for every device it creates so it can write on it. > > But this only happens, when the the storage gets added. After a reboot of the > system those rights are lost. There're a few solutions here to fix this in a > clean way: Either adding vdsm in the disk group (a group with read-write > permissions to block devices) or changing the rights when the storage goes up. > > I prefer the later method, because otherwise vdsm would have permissions to > access the device with the system on it and if somebody finds a bug in vdsm, it > would be easy for him to compromise the whole system. > > I haven't found the part in the source yet, where to change this, otherwise I'd > provided a patch. Actually it used to work this way and we removed it once we moved to rhel 6 due to the udev rule that always changes the permissions back to the disk group. Then we just added a set of udev rules that monitor and set device permissions if they look like they belong to vdsm. Granting vdsm permissions to change device permissions is effectively the same as adding it to the disk group. however vdsm could ask supervdsm to do this which would require a new verb in supervdsm which validates that the device to chown matches the same regex as the current udev rules (would probably need to refactor that out and auto-generate the udev rule set to avoid the duplication. This cannot be done in vdsm startup though as it is insufficient. storage can be dynamically added and (created on host A, exposed only on host B) and permissions would have to be set whenever new devices are available. So this would have to be introduced in several flows. Why not just use udev?
> Granting vdsm permissions to change device permissions is effectively the same > as adding it to the disk group. You are right. That's a problem, but could be fixed with a long and ugly sudo line. (The udev rule does almost the same and the sudo chown is already there and will stay there, for now) > Why not just use udev? It's ok. I just couldn't get it to work on my Debian/Testing system. But after a few experiments it turned out that I just had to change the order when the rules are called from 12 to 99 and now it works. (I guess 95 would work, too) Bug's closed.