On Fri, Feb 06, 2026 at 01:03:18AM +0100, Hannes Reinecke wrote: > On 2/5/26 14:39, Stefan Hajnoczi wrote: > > On Thu, Feb 05, 2026 at 12:01:13PM +0000, Daniel P. Berrangé wrote: > > > On Thu, Feb 05, 2026 at 12:52:33PM +0100, Martin Wilck wrote: > > > > On Wed, 2026-02-04 at 13:32 -0500, Stefan Hajnoczi wrote: > > > > > On Wed, Feb 04, 2026 at 02:19:48PM +0100, Martin Wilck wrote: > > > > > > Hi Stefan, > > > > > > > > > > > > So the ioctls will pass through qemu into the kernel, to be > > > > > > intercepted > > > > > > by the dm-mpath driver, which will use an upcall to have them > > > > > > handled > > > > > > by mpathpersistd (for the actual command) and multipathd (for the > > > > > > path > > > > > > registrations). > > > > > > > > > > > > I don't fully understand the advantage, security and complexity- > > > > > > wise, > > > > > > of this concept, compared to intercepting them qemu and using a > > > > > > socket > > > > > > to talk to mpathpersistd directly. If we did this, we could even > > > > > > support both generic and SCSI PR commands. > > > > > > > > > > Hi Martin, > > > > > The simplification and security benefits are on the application side, > > > > > not on the DM-Multipath side, so I can see what you're getting at. > > > > > From > > > > > the DM-Multipath perspective things get a little more complex. > > > > > > > > > > From an application perspective, a single API that works across block > > > > > device types (SCSI, NVMe, DM-Multipath) and requires no privileges or > > > > > sockets (they are a pain in container environments) is the most > > > > > convenient. The <linux/pr.h> ioctl API offers exactly this. > > > > > > > > I may be missing something, but AFAICS the PR ioctls require having a > > > > block device open for writing, which does either require root > > > > privileges, or some file descriptor previously opened with privileges > > > > and forwarded to another, less privileged process. No? > > > > > > While QEMU is run unprivileged, libvirt will grant QEMU access any block > > > devices that have been configured for the guest in question. On Linux, > > > libvirt will create a new /dev tmpfs populated with the allow-list of > > > device nodes the guest is permitted to access, with suitable file > > > permissions, ownership & SELinux labels set. > > > > Ultimately something does require privileges to give an unprivileged > > application access to a block device. That could be udev rules, it could > > be libvirt, etc. > > > > I would say the real distinction is between the privileges needed so the > > application can access the block device vs the privileges needed to > > perform PR operations. If udev or libvirt has set up block device nodes, > > an unprivileged application can open them for read/write access. But it > > would require CAP_SYS_RAWIO for SG_IO PR operations on top of that > > whereas <linux/pr.h> ioctls do not require that. > > > That would make sense, but unfortunately READ KEYS (and READ > RESERVATIONS) requires the same privileges than the other > blkpr functions. Might be an idea to change that, though.
Making sure I understand: blkdev_pr_read_keys() and blkdev_pr_read_reservation() in Linux block/ioctl.c should be adjusted to allow not just BLK_OPEN_WRITE but also BLK_OPEN_READ? I think it's okay from a security perspective: if the application can already read the entire disk, then it's okay for it to read the keys and reservation information. But I'm not 100% sure... In any case, I think this idea is orthogonal to the discussion about DM-Multipath <linux/pr.h> support. In terms of permission requirements, <linux/pr.h> already requires fewer permissions (just opening the block device for write) today than libmpathpersist or ioctl(SG_IO). Or do you see a scenario where the application wants to open the block device as root (or CAP_SYS_RAWIO) but read-only, so requiring opening the device with write permissions is a blocker? Stefan
signature.asc
Description: PGP signature
