[Devel] [PATCH hci-8.1] block: let container root set the block size of and flush its device

[Eva Kurchatova (Virtuozzo)]

On 10/21/26 23:56, Vladimir Riabchun wrote:
>
>
> On 10/21/26 19:54, Eva Kurchatova wrote:
>> BLKBSZSET and BLKFLSBUF check CAP_SYS_ADMIN in the initial user
>> namespace, so root in a container cannot set the block size of a block
>> device it has been given, nor flush its buffers, and mkfs.xfs on a loop
>> device there stops with "cannot set blocksize 512 on block device
>> /dev/loopN: Permission denied", or with "Flushing the data device
>> failed, err=13" once it gets past the first.
>>
>> Check the capability relative to the container, as the other block
>> code adapted for containers does. The device itself is reachable only
>> through the device cgroup, set_blocksize() still needs the device
>> exclusively, and a flush discards only cached pages of that device, so
>> nothing a container could not already write to is affected.
>>
>> https://virtuozzo.atlassian.net/browse/VSTOR-137668
>> Feature: ve: allow various syscalls in CT root userns
>>
>> Signed-off-by: Eva Kurchatova <eva.kurchatova at virtuozzo.com>
>> ---
>>   block/ioctl.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/ioctl.c b/block/ioctl.c
>> index a3c53b04e1e3..14047cd8e611 100644
>> --- a/block/ioctl.c
>> +++ b/block/ioctl.c
>> @@ -419,7 +419,7 @@ static int blkdev_pr_clear(struct block_device 
>> *bdev, blk_mode_t mode,
>>   static int blkdev_flushbuf(struct block_device *bdev, unsigned cmd,
>>           unsigned long arg)
>>   {
>> -    if (!capable(CAP_SYS_ADMIN))
>> +    if (!ve_capable(CAP_SYS_ADMIN))
>
> Is it possible that some evil CT user can spam flush, keep mutex most
> of the time and prevent some host actions?
> I'm mostly talking about ploop devices passed by vzctl.
>
I would imagine that the mutex fairness would not allow this,

given that the mutex enforces a wait queue. However, this could

lead to undesirable IO latency on the host, which is possible in

many other ways, esp. if the host uses a spinning disk.

Not allowing guests to flush properly can violate ACID consistency.

>>           return -EACCES;
>>         mutex_lock(&bdev->bd_holder_lock);
>> @@ -531,7 +531,7 @@ static int blkdev_bszset(struct file *file, 
>> blk_mode_t mode,
>>       struct file *excl_file;
>>       int ret, n;
>>   -    if (!capable(CAP_SYS_ADMIN))
>> +    if (!ve_capable(CAP_SYS_ADMIN))
>
> The same question regarding hdd disks from vzctl: can't we break them?
>
I'll look more into it, but generally the same points as above for now.

Best regards.

>>           return -EACCES;
>>       if (!argp)
>>           return -EINVAL;
>
> I'll check tomorrow what nasty thing could be done with them.
>