On Mon, Feb 09, 2026 at 01:50:00PM +0100, Hannes Reinecke wrote: > 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.
I see. I will send patches to change blkdev_pr_read_keys() blkdev_pr_read_reservation() to require only BLK_OPEN_READ. Stefan
signature.asc
Description: PGP signature
