| Message ID | 20230609102122.118800-1-jefflexu@linux.alibaba.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] block: relax permission for Persistent Reservations ioctl | expand |
On Fri, Jun 09, 2023 at 06:21:22PM +0800, Jingbo Xu wrote: > When the shared storage is accessed from containers [1], it's not > recommended to grant CAP_SYS_ADMIN to containers for access to > Persistent Reservations in risk of container escape. > > Remove the extra CAP_SYS_ADMIN permission constraint for Persistent > Reservations ioctl which shall do no harm [2]. I think we still to check that if CAP_SYS_ADMIN is not present, the file descriptors needs to be open for write, and we're not called on a partition (the latter should probbaly be always checked, as a reservation for a partitions doesn't make sense). But in general I think relaxing this is a good idea, we just need to be very careful. Looking at the discussion of unprivileged nvme command passthrough might be a good start.
On 6/10/23 2:06 PM, Christoph Hellwig wrote: > On Fri, Jun 09, 2023 at 06:21:22PM +0800, Jingbo Xu wrote: >> When the shared storage is accessed from containers [1], it's not >> recommended to grant CAP_SYS_ADMIN to containers for access to >> Persistent Reservations in risk of container escape. >> >> Remove the extra CAP_SYS_ADMIN permission constraint for Persistent >> Reservations ioctl which shall do no harm [2]. > > I think we still to check that if CAP_SYS_ADMIN is not present, > the file descriptors needs to be open for write, and we're not called > on a partition (the latter should probbaly be always checked, > as a reservation for a partitions doesn't make sense). > > But in general I think relaxing this is a good idea, we just need to > be very careful. Looking at the discussion of unprivileged nvme > command passthrough might be a good start. Hi, Thanks for the reply. It seems I need to dive deeper into details of Persistent Reservations protocol and the permission control you mentioned in nvme command passthrough. Thanks for your suggestions. I will send a new version later.
diff --git a/block/ioctl.c b/block/ioctl.c index 9c5f637ff153..46c9ac43bbf8 100644 --- a/block/ioctl.c +++ b/block/ioctl.c @@ -260,8 +260,6 @@ static int blkdev_pr_register(struct block_device *bdev, const struct pr_ops *ops = bdev->bd_disk->fops->pr_ops; struct pr_registration reg; - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; if (!ops || !ops->pr_register) return -EOPNOTSUPP; if (copy_from_user(®, arg, sizeof(reg))) @@ -278,8 +276,6 @@ static int blkdev_pr_reserve(struct block_device *bdev, const struct pr_ops *ops = bdev->bd_disk->fops->pr_ops; struct pr_reservation rsv; - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; if (!ops || !ops->pr_reserve) return -EOPNOTSUPP; if (copy_from_user(&rsv, arg, sizeof(rsv))) @@ -296,8 +292,6 @@ static int blkdev_pr_release(struct block_device *bdev, const struct pr_ops *ops = bdev->bd_disk->fops->pr_ops; struct pr_reservation rsv; - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; if (!ops || !ops->pr_release) return -EOPNOTSUPP; if (copy_from_user(&rsv, arg, sizeof(rsv))) @@ -314,8 +308,6 @@ static int blkdev_pr_preempt(struct block_device *bdev, const struct pr_ops *ops = bdev->bd_disk->fops->pr_ops; struct pr_preempt p; - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; if (!ops || !ops->pr_preempt) return -EOPNOTSUPP; if (copy_from_user(&p, arg, sizeof(p))) @@ -332,8 +324,6 @@ static int blkdev_pr_clear(struct block_device *bdev, const struct pr_ops *ops = bdev->bd_disk->fops->pr_ops; struct pr_clear c; - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; if (!ops || !ops->pr_clear) return -EOPNOTSUPP; if (copy_from_user(&c, arg, sizeof(c)))
When the shared storage is accessed from containers [1], it's not recommended to grant CAP_SYS_ADMIN to containers for access to Persistent Reservations in risk of container escape. Remove the extra CAP_SYS_ADMIN permission constraint for Persistent Reservations ioctl which shall do no harm [2]. [1] https://lore.kernel.org/linux-block/345a7cdc-e55b-7aaa-43d4-59b3f911ef18@linux.alibaba.com/ [2] https://lore.kernel.org/linux-block/ZGxaxnOeadVwb2gR@infradead.org/ Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com> --- I also noticed that the extra CAP_SYS_ADMIN permission constraint is not added until v4 [*] of original pull request for Persistent Reservation API. [*] https://lore.kernel.org/all/1444911052-9423-1-git-send-email-hch@lst.de/ --- block/ioctl.c | 10 ---------- 1 file changed, 10 deletions(-)