linux-kernel - Re: [PATCH 0/4] fs: add mount

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8f815e88-d51d-9f70-89f1-a7f54b1200ce@virtuozzo.com>
Date:   Thu, 1 Oct 2020 17:17:53 +0300
From:   Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
To:     Christian Brauner <christian.brauner@...ntu.com>,
        David Howells <dhowells@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Andrew Vagin <avagin@...tuozzo.com>
Subject: Re: [PATCH 0/4] fs: add mount_setattr()

> 
> mount_setattr() can be expected to grow over time and is designed with
> extensibility in mind. It follows the extensible syscall pattern we have
> used with other syscalls such as openat2(), clone3(),
> sched_{set,get}attr(), and others.
> The set of mount options is passed in the uapi struct mount_attr which
> currently has the following layout:
> 
> struct mount_attr {
> 	__u64 attr_set;
> 	__u64 attr_clr;
> 	__u32 propagation;
> 	__u32 atime;
> };
> 

We probably can rework "mnt: allow to add a mount into an existing 
group" (MS_SET_GROUP https://lkml.org/lkml/2017/1/23/712) to an 
extension mount_setattr. Do anyone have any objections?

We need it in CRIU because it is a big problem to restore complex mount 
trees with complex propagation flags (see my LPC talk for details 
https://linuxplumbersconf.org/event/7/contributions/640/) of 
system-containers.

If we allow set(copy) sharing options we can separate mount tree restore 
and propagation restore and everything becomes much simpler. (And we 
already have CRIU implementation based on it, which helps with variety 
of bugs with mounts we previously had. 
https://src.openvz.org/projects/OVZ/repos/criu/browse/criu/mount-v2.c#880)

I've also tried to consider another approach 
https://github.com/Snorch/linux/commit/84886f588527b062993ec3e9760c879163852518 
to disable actual propagation while restoring the mount tree. But with 
this approach it looks like it would be still hard to restore in CRIU 
because: With "MS_SET_GROUP" we don't care about roots. Imagine we have 
mount A (shared_id=1, root="/some/sub/path") and mount B (master_id=1, 
root="/some/other/sub/path", with MS_SET_GROUP we can copy sharing from 
mount A to B and make B MS_SLAVE to restore them. In case we want to do 
the same with only inheritance we would have to have some helper mount 
in this share C (shared_id=1, root="/") so that B can inherit this share...

-- 
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.