From: "Eva Kurchatova (Virtuozzo)" <eva.kurchatova@virtuozzo.com>
To: Konstantin Khorenko <khorenko@virtuozzo.com>, devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 v3] block: let container root set the block size of and flush its device
Date: Thu, 29 Oct 2026 18:06:39 +0200 [thread overview]
Message-ID: <bc754a03-f706-470f-afa6-3b9656ebc236@virtuozzo.com> (raw)
In-Reply-To: <20261029-vstor-137668-block-let-container-root-set-the-block-size-v3-1-c3fd7db3777c@virtuozzo.com>
On 10/29/26 18:00, Konstantin Khorenko wrote:
> From: Eva Kurchatova <eva.kurchatova@virtuozzo.com>
>
> 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, and let container root through only
> where its device cgroup grants write access to the device: a device
> handed to a container read-only may be held by a filesystem outside
> it, and neither its cache nor its block size should be touched from
> inside.
>
> https://virtuozzo.atlassian.net/browse/VSTOR-137668
> Feature: ve: allow various syscalls in CT root userns
>
> Signed-off-by: Eva Kurchatova <eva.kurchatova@virtuozzo.com>
> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
> ---
> Root in a container cannot run mkfs.xfs on a block device it has been
> given: BLKBSZSET and BLKFLSBUF want CAP_SYS_ADMIN in the initial user
> namespace. The patch checks the capability relative to the container
> and lets container root through only where its device cgroup grants
> write access to the device.
>
> v2 also refused BLKFLSBUF from a container with -EBUSY when a
> filesystem was mounted on the device. v3 drops that: the path is
> reachable only with a write grant on the device, and with that grant
> the container can already overwrite the filesystem under the mount, so
> forcing its writeback through fs_bdev_sync() is strictly less. The
> sync is what syncfs() does, bd_holder_lock is dropped before it, and
> invalidate_bdev() frees clean pages only. A container's own mounted
> loop device now behaves as on the host.
>
> CT disks handed out by vzctl are not affected: libvzctl grants them
> write access for mount only, which bdev_permission(BLK_OPEN_WRITE)
> does not satisfy, so they keep getting -EACCES as before.
>
> BLKROSET and BLKRASET stay under capable(): the former flips
> BD_READ_ONLY on a device the host may hold, the latter writes the
> per-disk bdi shared with the host and every partition. The neoltp CI
> carries strict XFAIL rules for the affected tests (PSBM-139222,
> PSBM-139077); the xfs ones start passing with this kernel and need a
> kernel-version condition, ioctl04 and ioctl06 keep failing.
>
> Assisted-by: LLM
> ---
> Changes in v3:
> - Drop the -EBUSY refusal of BLKFLSBUF on a mounted device from a
> container, a device the container can write to is synced as on the
> host (Pavel Tikhomirov).
> - Add Pavel's Reviewed-by.
> - Link to v2: http://lore.virtuozzo.com/20261022022554.2427456-1-eva.kurchatova@virtuozzo.com
>
> Changes in v2:
> - Device in read-only cannot be flushed or have its block size changed
> from CT, depending on cgroup grant. Host path unchanged.
> - Device with mounted filesystem denies flush from a container with
> EBUSY. Container syncs its own mounts via the filesystem.
> - Host and container told apart by ve_is_super(), not by a failing
> capable().
> - Corrected the claims in the commit message.
> - Link to v1: http://lore.virtuozzo.com/20261021175410.2339797-1-eva.kurchatova@virtuozzo.com
>
> To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
> To: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
> ---
> block/ioctl.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/block/ioctl.c b/block/ioctl.c
> index a3c53b04e1e34..c49a35b01cb05 100644
> --- a/block/ioctl.c
> +++ b/block/ioctl.c
> @@ -9,6 +9,7 @@
> #include <linux/backing-dev.h>
> #include <linux/fs.h>
> #include <linux/blktrace_api.h>
> +#include <linux/ve.h>
> #include <linux/pr.h>
> #include <linux/uaccess.h>
> #include <linux/pagemap.h>
> @@ -416,10 +417,20 @@ static int blkdev_pr_clear(struct block_device *bdev, blk_mode_t mode,
> return ops->pr_clear(bdev, c.key);
> }
>
> +/* Container root administers only a device its device cgroup lets it write */
> +static bool blkdev_admin_capable(struct block_device *bdev)
> +{
> + if (!ve_capable(CAP_SYS_ADMIN))
> + return false;
> +
> + return ve_is_super(get_exec_env()) ||
> + !bdev_permission(bdev->bd_dev, BLK_OPEN_WRITE, NULL);
> +}
> +
> static int blkdev_flushbuf(struct block_device *bdev, unsigned cmd,
> unsigned long arg)
> {
> - if (!capable(CAP_SYS_ADMIN))
> + if (!blkdev_admin_capable(bdev))
> return -EACCES;
>
> mutex_lock(&bdev->bd_holder_lock);
> @@ -527,11 +538,12 @@ static int blkdev_bszset(struct file *file, blk_mode_t mode,
> {
> // this one might be file_inode(file)->i_rdev - a rare valid
> // use of file_inode() for those.
> - dev_t dev = I_BDEV(file->f_mapping->host)->bd_dev;
> + struct block_device *bdev = I_BDEV(file->f_mapping->host);
> + dev_t dev = bdev->bd_dev;
> struct file *excl_file;
> int ret, n;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!blkdev_admin_capable(bdev))
> return -EACCES;
> if (!argp)
> return -EINVAL;
>
> ---
> base-commit: 0a88195dfe7ad750d8e0d9815e70515a03b270f1
> change-id: 20261029-vstor-137668-block-let-container-root-set-the-block-size-70922fd9b2a5
>
> Best regards,
> --
> Konstantin Khorenko,
> Virtuozzo Linux Kernel Team
Acknowledged-by: Eva Kurchatova <eva.kurchatova@virtuozzo.com>
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-10-29 16:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 16:00 Konstantin Khorenko
2026-10-29 16:04 ` no-reply
2026-10-29 16:06 ` Eva Kurchatova (Virtuozzo) [this message]
2026-10-29 16:10 ` Konstantin Khorenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc754a03-f706-470f-afa6-3b9656ebc236@virtuozzo.com \
--to=eva.kurchatova@virtuozzo.com \
--cc=devel@openvz.org \
--cc=khorenko@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.