[RFC] block: relax permission for Persistent Reservations ioctl

[RFC] block: relax permission for Persistent Reservations ioctl

[Jingbo Xu]

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(-)

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(&reg, 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)))
-- 
2.19.1.6.gb485710b

Re: [RFC] block: relax permission for Persistent Reservations ioctl

[Christoph Hellwig]

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.

Re: [RFC] block: relax permission for Persistent Reservations ioctl

[Jingbo Xu]

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.

-- 
Thanks,
Jingbo