Re: [RFC PATCH 1/7] block: Support creating a struct file from a block device
From: Demi Marie Obenour <hidden>
Date: 2023-02-01 16:19:14
Also in:
lkml
On Tue, Jan 31, 2023 at 11:45:55PM -0800, Christoph Hellwig wrote:
On Tue, Jan 31, 2023 at 11:27:59AM -0500, Demi Marie Obenour wrote:quoted
While it is easy to provide userspace with an FD to any struct file, it is *not* easy to obtain a struct file for a given struct block_device. I could have had device-mapper implement everything itself, but that would have duplicated a large amount of code already in the block layer. Instead, I decided to refactor the block layer to provide a function that does exactly what was needed. The result was this patch. In the future, I would like to add an ioctl for /dev/loop-control that creates a loop device and returns a file descriptor to the loop device. I could also see iSCSI supporting this, with the socket file descriptor being passed in from userspace.And it is somewhat intentional that you can't. Block device inodes have interesting life times and are never directly exposed to userspace at all. They are internal, and only f_mapping of a file system inode delegates to them or I/O. Your patch now magically exposes them to userspace.
The intention is that the file descriptor is equvalent to what one would get by first creating the device and then opening it. If it is not, that is a bug in one of my patches.
And it then bypasses all pathname and inode permission based access checks and auditing. So we can't just do it.
Accessing /dev/mapper/control is already enough to panic the kernel, so presumably only fully trusted userspace can make the ioctl to begin with. Furthermore, this only allows a userspace process to get a file descriptor to the device-mapper device it itself created.
quoted
blkdev_do_open() does not solve any problem for me at this time. Instead, it represents the code shared by blkdev_get_by_dev() and blkdev_get_file(). I decided to export it because it could be of independent use to others. In particular, it could potentially simplify disk_scan_partitions() in block/genhd.c, pkt_new_dev() in pktcdvd, backing_dev_store() in zram, and f2fs_scan_devices() in f2fs.All thse need to actually open the underlying device as they do I/O. Doing I/O without opening the device is a no-go.
blkdev_do_open() *does* open the device. If it doesn’t, that’s a bug. In v2 I will add the same access control checks that blkdev_get_by_dev() does. Is this sufficient? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachments
- signature.asc [application/pgp-signature] 833 bytes