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?

Yes. This requires not too many changes to the actual filesystems as you
can see from the xfs conversion that Christoph has done.

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

The most interesting quota codepaths I audited are dquot_transfer that
transfers quota from one inode to another one during setattr. That
happens via a struct iattr which will already contain correctly
translated ia_uid and ia_gid values according to the mount the caller is
coming from. I'll take another close look at that now and add tests for
that if I can find some in xfstests.

whether there can exist processes with CAP_SYS_ADMIN and an idmapped
mount?  Syscalls like bulkstat and quotactl present file [ug]ids to

Yes, that should be possible.

programs, but afaict there won't be any translating going on?

quotactl operates on the superblock. So the caller would need a mapping
in the user namespace of the superblock. That doesn't need to change.
But we could in the future extend this to be on a per-mount basis if
this was a desired use-case. I don't think it needs to happen right now
though.

(To be fair, bulkstat is an xfs-only thing, but quota control isn't.)

I'm certain we'll find more things to cover after the first version has
landed. :)
We for sure won't cover it all in the first iteration.

I'll start skimming the patchset...

Thanks!
Christian