2023-06-09 10:44:42

by Jingbo Xu

[permalink] [raw]
Subject: [RFC] block: relax permission for Persistent Reservations ioctl

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/[email protected]/
[2] https://lore.kernel.org/linux-block/[email protected]/

Signed-off-by: Jingbo Xu <[email protected]>
---
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/[email protected]/
---
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



2023-06-10 06:17:00

by Christoph Hellwig

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

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.

2023-06-10 08:35:43

by Jingbo Xu

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



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