Re: [PATCH 00/18] overlay: support idmapped layers

[Giuseppe Scrivano <gscrivan@redhat.com>]

Christian Brauner <brauner@kernel.org> writes:

> On Wed, Mar 30, 2022 at 04:58:03PM -0400, Vivek Goyal wrote:
>> On Tue, Mar 29, 2022 at 12:35:07PM +0200, Christian Brauner wrote:
>> > From: "Christian Brauner (Microsoft)" <brauner@kernel.org>
>> > 
>> > Hey,
>> > 
>> > This adds support for mounting overlay on top of idmapped layers.
>> > 
>> > I have to start by saying a massive thank you to Amir! He did not just
>> > answer my constant overlay questions but also provided quite a few
>> > patches himself in this series in addition to reviews, comments and a
>> > lot of suggestions. Thank you!
>> > 
>> > There have been a lot of requests to unblock this. For just a few select
>> > examples see [3], [4], and [5]. I've worked closely with various
>> > communities among them containerd, Kubernetes, Podman, LXD, runC, crun,
>> > and systemd (For the curious please see the various pull-request and
>> > issues below.) a lot of them already support idmapped mounts since they
>> > are enabled for btrfs, ext4, and xfs (and f2fs and fat fwiw). In
>> > additon, a few colleagues at Microsoft and from Red Hat work on a
>> > Kubernetes Enhancement Proposals (KEP) that also relies on overlayfs
>> > supporting idmapped layers, see [12].
>> > 
>> > Overlayfs on top of idmapped layers will be used in various ways:
>> > 
>> > * Container managers use overlayfs to efficiently share layers between
>> >   containers. However, this only works for privileged containers.
>> >   Layers cannot be shared if both privileged and unprivileged containers
>> >   are used. Layers can also not be shared if non-overlapping idmappings
>> >   are used for unprivileged containers. Layers cannot be shared because
>> >   of the conflicting ownership requirements between the containers.
>> 
>> Hi Christian,
>> 
>> Thank you for this work. This is awesome.
>
> Thanks for saying that! Appreciate it.
>
>> 
>> Wanted to test it. I was wondering how to test it. Some simple
>> instructions will help.
>
> Of course. There are various ways:
>
> 1. Giuseppe has already put up support the containers/storage go library:
>    https://github.com/containers/storage/pull/1180
>    and he's been running workloads with that branch. If you're familiar
>    with that tooling you can just use that.

Vivek, if you vendor the containers/storage branch into Podman you can run something like:

# podman run --uidmap 0:2000:40000 --gidmap 0:8000:50000 --rm fedora sh -c 'grep . /proc/self/?id_map; ls -l /'
/proc/self/gid_map:         0       8000      50000
/proc/self/uid_map:         0       2000      40000
total 16
lrwxrwxrwx.   1 root   root      7 Jul 21  2021 bin -> usr/bin
dr-xr-xr-x.   1 root   root      0 Jul 21  2021 boot
drwxr-xr-x.   5 root   root    340 Mar 31 09:46 dev
drwxr-xr-x.   1 root   root   1682 Mar 31 09:45 etc
drwxr-xr-x.   1 root   root      0 Jul 21  2021 home
lrwxrwxrwx.   1 root   root      7 Jul 21  2021 lib -> usr/lib
lrwxrwxrwx.   1 root   root      9 Jul 21  2021 lib64 -> usr/lib64
drwx------.   1 root   root      0 Feb 21 06:47 lost+found
drwxr-xr-x.   1 root   root      0 Jul 21  2021 media
drwxr-xr-x.   1 root   root      0 Jul 21  2021 mnt
drwxr-xr-x.   1 root   root      0 Jul 21  2021 opt
dr-xr-xr-x. 262 nobody nobody    0 Mar 31 09:46 proc
dr-xr-x---.   1 root   root    206 Mar 31 09:45 root
drwxr-xr-x.   1 root   root     40 Mar 31 09:46 run
lrwxrwxrwx.   1 root   root      8 Jul 21  2021 sbin -> usr/sbin
drwxr-xr-x.   1 root   root      0 Jul 21  2021 srv
dr-xr-xr-x.  12 nobody nobody    0 Mar 31 09:42 sys
drwxrwxrwt.   1 root   root      0 Feb 21 06:47 tmp
drwxr-xr-x.   1 root   root    100 Feb 21 06:47 usr
drwxr-xr-x.   1 root   root    154 Feb 21 06:47 var

you'll notice that it is using idmapped mounts because the container
starts immediately when you change the mappings; without these kernel
patches Podman needs to chown the image first.

Regards,
Giuseppe