[pkg-go] Bug#1042090: podman: fails to start container with userns mapping

[Reinhard Tartler]

Control: tag -1 +upstream +moreinfo

Hi Hristo,

Thanks for taking the time to report this issue. In the meantime, podman
4.5 is now in debian/testing (and 4.6.2 in debian/experimental). Can you
please upgrade your package and give it another try? If you're right, you
shouldn't see this issue anymore. Please report back so that I can mark
this as fixed in the Debian bug tracker.

Best,
-rt

On Wed, Jul 26, 2023 at 10:51 AM Hristo Venev <hristo at venev.name> wrote:

> Package: podman
> Version: 4.3.1+ds1-8+b1
> Severity: normal
> X-Debbugs-Cc: hristo at venev.name
>
> Dear Maintainer,
>
> When trying to run a container using podman (as root) with a uid/gid
> mapping specified via `--userns`, it fails to start:
>
> > # podman run --rm --userns
> auto:uidmapping=1000:1001:1,gidmapping=1000:1001:1 debian:12
> > ERRO[0000] Unmounting
> /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged: invalid argument
> > Error: mounting storage for container INSERT_ANOTHER_ID_HERE: creating
> overlay mount to /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged,
> mount_data="lowerdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/diff1:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_ANOTHER_SHORT_ID_HERE,upperdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/diff,workdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/work,,volatile":
> permission denied
>
> The following appears in the kernel log:
> > [TIME] overlayfs: failed to resolve
> '/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE':
> -13
>
> The outcome is listed above. The expected outcome was that the container
> would start, with most IDs mapped from those delegated to the
> `containers` user, except uid/gid 1000 inside the container which
> correspond to 1001 outside.
>
> Running the container with just `--userns auto` works. However, then all
> files passed to the container via bind mounts would be owned by
> nobody:nogroup instead of 1000:1000.
>
> This seems similar to https://github.com/containers/podman/issues/18435,
> which was probably fixed in podman 4.5.0.
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.3.0-1-amd64 (SMP w/24 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages podman depends on:
> ii  conmon                           2.1.6+ds1-1
> ii  crun                             1.8.5-1
> ii  golang-github-containers-common  0.50.1+ds1-4
> ii  libc6                            2.37-6
> ii  libdevmapper1.02.1               2:1.02.185-2
> ii  libgpgme11                       1.18.0-3+b1
> ii  libseccomp2                      2.5.4-1+b3
> ii  libsubid4                        1:4.13+dfsg1-1+b1
>
> Versions of packages podman recommends:
> pn  buildah                       <none>
> pn  catatonit | tini | dumb-init  <none>
> pn  dbus-user-session             <none>
> pn  fuse-overlayfs                <none>
> pn  slirp4netns                   <none>
> pn  uidmap                        <none>
>
> Versions of packages podman suggests:
> pn  containers-storage  <none>
> pn  docker-compose      <none>
> ii  iptables            1.8.9-2
>
> -- no debconf information
>
>

-- 
regards,
    Reinhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20230918/e4f6addd/attachment-0001.htm>