On Thu, Jan 14, 2021 at 09:12:41AM -0800, Darrick J. Wong wrote:

On Tue, Jan 12, 2021 at 11:00:42PM +0100, Christian Brauner wrote:

quoted

Hey everyone,

The only major change is the inclusion of hch's patch to port XFS to
support idmapped mounts. Thanks to Christoph for doing that work.

Yay :)

quoted

(For a full list of major changes between versions see the end of this
 cover letter.
 Please also note the large xfstests testsuite in patch 42 that has been
 kept as part of this series. It verifies correct vfs behavior with and
 without idmapped mounts including covering newer vfs features such as
 io_uring.
 I currently still plan to target the v5.12 merge window.)

With this patchset we make it possible to attach idmappings to mounts,
i.e. simply put different bind mounts can expose the same file or
directory with different ownership.
Shifting of ownership on a per-mount basis handles a wide range of
long standing use-cases. Here are just a few:
- Shifting of a subset of ownership-less filesystems (vfat) for use by
  multiple users, effectively allowing for DAC on such devices
  (systemd, Android, ...)
- Allow remapping uid/gid on external filesystems or paths (USB sticks,
  network filesystem, ...) to match the local system's user and groups.
  (David Howells intends to port AFS as a first candidate.)
- Shifting of a container rootfs or base image without having to mangle
  every file (runc, Docker, containerd, k8s, LXD, systemd ...)
- Sharing of data between host or privileged containers with
  unprivileged containers (runC, Docker, containerd, k8s, LXD, ...)
- Data sharing between multiple user namespaces with incompatible maps
  (LXD, k8s, ...)

That sounds neat.  AFAICT, the VFS passes the filesystem a mount userns
structure, which is then carried down the call stack to whatever
functions actually care about mapping kernel [ug]ids to their ondisk
versions?

Does quota still work after this patchset is applied?  There isn't any
mention of that in the cover letter and I don't see a code patch, so
does that mean everything just works?  I'm particularly curious about
whether there can exist processes with CAP_SYS_ADMIN and an idmapped
mount?  Syscalls like bulkstat and quotactl present file [ug]ids to
programs, but afaict there won't be any translating going on?

bulkstat is not allowed inside user namespaces. It's an init
namespace only thing because it provides unchecked/unbounded access
to all inodes in the filesystem, not just those contained within a
specific mount container.

Hence I don't think bulkstat output (and other initns+root only
filesystem introspection APIs) should be subject to or concerned
about idmapping.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com