shadow package does not set setuid bit on newgidmap newuidmap, so lxc unprivileged containers cannot start. According to lxc this is a distro/package issue. Reproducible: Always Steps to Reproduce: 1. create an unprivileged lxc container 2. update/remerge shadow ebuild 3. start the container Actual Results: lxc container cannot start Expected Results: lxc container should start Check the problem and the solution here: https://github.com/lxc/lxc/issues/1454 Maybe an additional useflag is needed in shadow ebuild so we can setuid those binaries.
Confirmed, same problem here. I'm currently working around the problem by disabling the use of shadow's newgidmap newuidmap by passing EXTRA_ECONF="--enable-subordinate-ids=no" to sys-apps/shadow during ./configure as LXC's implementation is somewhat flaky in my use case. This has the end of result of LXC correctly setting up the UID/GID mapping directly itself instead of trying (and failing) to use shadow's newgidmap newuidmap.
(In reply to Rick Harris from comment #1) > Confirmed, same problem here. > > I'm currently working around the problem by disabling the use of shadow's > newgidmap newuidmap by passing EXTRA_ECONF="--enable-subordinate-ids=no" to > sys-apps/shadow during ./configure as LXC's implementation is somewhat flaky > in my use case. > > This has the end of result of LXC correctly setting up the UID/GID mapping > directly itself instead of trying (and failing) to use shadow's newgidmap > newuidmap. Nice, can you attach a patch? How do you do it?
CCing lxc maintainers. Not sure if this is still an issue or not?
No it shouldn't be, a lot has changed how lxc handles idmap since 2017. If it is with latest lxc in the tree, please reopen and let's investigate again.