Re: Moving from qemu-pr-helper and libmpathpersist to <linux/pr.h>

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]