On 2/6/26 15:08, Stefan Hajnoczi wrote:
On Fri, Feb 06, 2026 at 01:03:18AM +0100, Hannes Reinecke wrote:
On 2/5/26 14:39, Stefan Hajnoczi wrote:
[ .. ]
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?
Yes.
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?
My concern with opening the block device with BLK_OPEN_WRITE is that
this will trigger udev to 'synthesize' (ie regenerate) an 'add' event
on close, causing 'interesting' effects as this will cascade down
through the udev rule chain, triggering blkid, partition scan, you
name it.
Horrible, horrible, horrible.
Don't do it.
Especially not as you are only interested in reading information,
and not changing the disk state in any way.
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
