rootless inside rootless not work

[mgoltzsche]

rootless inside rootless not work

[mgoltzsche]

I am working on it now within #49... and #50.

[mgoltzsche]

@calvin2021y please try again using the new 4.4.1 release.

[mgoltzsche]

I assume you used podman 4.2.1.
It wasn't working within upstream podman for a long time. Though I think I've seen somewhere in the release notes a line saying that it (or sth about it) was fixed but I did not try it again. Does it work with the official fedora-based podman image now or rather did you test that?

[mgoltzsche]

Though, I think nested user namespaces are problematic anyway since you're likely to exceed the uid/gid mapping. Increasing the uid/gid map on the host might map.

[mgoltzsche]

Btw which podman image did you use? (minimal or regular)
Did you run the outer container as --privileged?

[calvin2021y]

Thanks for reply.

I use latest with --privileged(not minimal), and fedora-based podman work.

I am aware uid/gid map issue and it will not be a issue.

one more extra question: for rootful inside rootless with --privileged, the iptable and bridge will work like host rootful podman ?

[calvin2021y]

here is the example for the rootful inside rootless with fedora

cat /proc/self/gid_map
         0       1001          1
         1     100000      65536

podman run --net slirp4netns -it --rm alpine cat /proc/self/gid_map
         0       1000          1
         1          1        999
      1000       1001      64535

podman run --net slirp4netns -it --rm alpine ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether ce:f1:63:ac:12:d8 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fd00::ccf1:63ff:feac:12d8/64 scope global dynamic flags 100 
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fe80::ccf1:63ff:feac:12d8/64 scope link 
       valid_lft forever preferred_lft forever

[mgoltzsche]

Looks like something is wrong with the subuid/subgid mapping within the static podman image then. Maybe over the weekend I can spare some time to look into it. A pull request would also be welcome 😉.

for rootful inside rootless with --privileged, the iptable and bridge will work like host rootful podman ?

Yes, mostly: You can perform administrative tasks within your unprivileged user's network namespace (backed by slirp4netns). While you can probably not bridge to any other network devices on the host that are not managed by slirp4netns, it should be possible to do so for slirp4netns-managed network namespaces owned by the same user or rather for multiple child containers of a shared parent container.

[calvin2021y]

with latest docker image, run podman (non-root) in porman (non-root) get this warinig:

WARN[0000] Additional gid=1 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=2 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=3 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=4 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=6 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=10 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=11 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=20 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=26 is not present in the user namespace, skip setting it 
WARN[0000] Additional gid=27 is not present in the user namespace, skip setting it 

I need to remove /etc/sub* to try this.

[calvin2021y]

podman 4.4 released, any plan to upgrade ?

[mgoltzsche]

I am closing the issue since I think the fix worked. Feel free to reopen if that's not the case.
It was partially a duplicate of #40.