Re: [PATCH 00/34] fs: idmapped mounts

Hi Eric, On Thu, Oct 29, 2020 at 10:47:49AM -0500, Eric W. Biederman wrote: > Christian Brauner <christian.brauner(a)ubuntu.com&gt; writes: > > > Hey everyone, > > > > I vanished for a little while to focus on this work here so sorry for > > not being available by mail for a while. > > > > Since quite a long time we have issues with sharing mounts between > > multiple unprivileged containers with different id mappings, sharing a > > rootfs between multiple containers with different id mappings, and also > > sharing regular directories and filesystems between users with different > > uids and gids. The latter use-cases have become even more important with > > the availability and adoption of systemd-homed (cf. [1]) to implement > > portable home directories. > > Can you walk us through the motivating use case? > > As of this year's LPC I had the distinct impression that the primary use > case for such a feature was due to the RLIMIT_NPROC problem where two > containers with the same users still wanted different uid mappings to > the disk because the users were conflicting with each other because of > the per user rlimits. > > Fixing rlimits is straight forward to implement, and easier to manage > for implementations and administrators. Our use case is to have the same directory exposed to several different containers which each have disjoint ID mappings. > Reading up on systemd-homed it appears to be a way to have encrypted > home directories. Those home directories can either be encrypted at the > fs or at the block level. Those home directories appear to have the > goal of being luggable between systems. If the systems in question > don't have common administration of uids and gids after lugging your > encrypted home directory to another system chowning the files is > required. > > Is that the use case you are looking at removing the need for > systemd-homed to avoid chowning after lugging encrypted home directories > from one system to another? Why would it be desirable to avoid the > chown? Not just systemd-homed, but LXD has to do this, as does our application at Cisco, and presumably others. Several reasons: * the chown is slow * the chown requires somewhere to write the delta in metadata (e.g. an overlay workdir, or an LV or something), and there are N copies of this delta, one for each container. * it means we need to have a +w filesystem at some point during execution. * it's ugly :). Conceptually, the kernel solves the uid shifting problem for us for most other kernel subsystems (including in a limited way fscaps) by configuring a user namespace. It feels like we should be able to do the same with the VFS.