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

[Konstantin Khorenko <khorenko@virtuozzo.com>]

> Is it possible that some evil CT user can spam flush, keep mutex most
> of the time and prevent some host actions?

No. bd_holder_lock is held only across the holder pointer test. The
->sync branch goes through bdev_super_lock(), which drops it before
taking s_umount and running sync_filesystem(). The other branch unlocks
before sync_blockdev(). Nothing heavy runs under it, so mount, umount,
freeze and mark_dead on the host are not affected.

> I'm mostly talking about ploop devices passed by vzctl.

In v2 those never reach the ioctl body. libvzctl configure_disk_perm()
grants CT disks (root ploop, secondary ploop, physical hdd via
use_device) r + W, plus M for non-root. W is "write only for mount": the
BPF program in bpf/cgroup_dev.c passes WRITE only when the request also
carries MOUNT. bdev_permission(BLK_OPEN_WRITE) has no MOUNT bit, so
blkdev_admin_capable() fails and the CT gets -EACCES, same as today.

> The same question regarding hdd disks from vzctl: can't we break them?

Even with a plain write grant, no. They are mounted by the host.
BLKFLSBUF hits the fs holder and v2 returns -EBUSY there. BLKBSZSET
cannot get the exclusive claim the mount holds and returns -EBUSY by the
unchanged upstream logic.

What v1 actually allowed on the CT's own ploop was sync plus
invalidate_bdev of the device under its own filesystem, i.e. what
syncfs() on its root already gives it. v2 closes even that at the
device cgroup level.
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel