Christian Brauner <brauner@xxxxxxxxxx> 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@xxxxxxxxxx> >> > >> > 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
