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.
Therefore there is a real advantages regarding privileges when using
<linux/pr.h> ioctls vs libmpathpersist.
There actually is a large argument here, namely that blkpr is
device independent. So when using it it doesn't matter whether
you are accessing a SCSI device or a NVME device, blkpr will
work in both cases.
And as such it's a far better choice for generic frameworks
like qemu.
For multipath less so, I agree, as that is pretty much SCSI-only.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
