rootless container + server app in Rust language -> Address not available (os error 99)

[Folaht]

Title used to be: "Does netavark run in rootless and it require special parameters to run a server app on it?"

The focus is now more on the actual error.
I'm not able to start the same network app rootless, despite the same parameters as rootfull.

App error

Error:
   0: Cannot start node (log path: /home/admin/.safe/node/node_dir_0). If this is the first node on the network pass the local address to be used using --first
   1: Cannot connect to the endpoint: Address not available (os error 99)
   2: Address not available (os error 99)

Location:
   sn/src/bin/sn_node.rs:315

https://github.com/maidsafe/safe_network/blob/main/sn/src/bin/sn_node.rs#L315

Run command

podman run --name root_node --restart unless-stopped --publish 192.168.178.26:12000-12015:12000-12015/udp --env CON_IP=10.88.0.2 --env CON_PORT=12000 --env PUB_IP=my.ip.v.4 --env PUB_PORT=12000 --env VERBOSE=-vvvv --mount type=bind,source=/home/folaht/.local/share/safe/cli/,destination=/home/admin/.safe/cli/ -d ghcr.io/safenetwork-community/rootnode-ipv4:latest

podman inspect podman

[
     {
          "name": "podman",
          "id": "2f259bab93aaaaa2542ba43ef33eb990d0999ee1b9924b557b7be53c0b7a1bb9",
          "driver": "bridge",
          "network_interface": "podman0",
          "created": "2022-04-06T15:31:13.564911141+02:00",
          "subnets": [
               {
                    "subnet": "10.88.0.0/16",
                    "gateway": "10.88.0.1"
               }
          ],
          "ipv6_enabled": false,
          "internal": false,
          "dns_enabled": false,
          "ipam_options": {
               "driver": "host-local"
          }
     }
]

Podman network info

$ podman info --format {{.Host.NetworkBackend}}
netavark

[mheon]

Netavark does work without root, but rootless networking in general is much more limited than root networking in general, so you are likely running into limitations in how rootless networking works. In general: rootless containers connected to networks do have IP addresses, but they are exclusively for communicating with other rootless containers. They are confined to the rootless network namespace; the host cannot ping them or contact them, for example (unless podman unshare --rootless-cni is used to join the rootless network namespace).

[Luap99]

The only way to connect to rootless containers from the outside is with forwarded ports. Rootless users have simply no privileges to create interfaces routing rules on the host.

If you want to get more security with root containers look into the --userns=auto option

[Folaht]

"The only way to connect to rootless containers from the outside is with forwarded ports."

How does that differ from what I think is my current setup?

interface podman0: 10.88.0.2:12000 -> eth0 interface 192.168.x.x:12000 -> modem interface i.p.v.4:12000
(port 12000 forwarded on modem settings)

$ podman port root_node
12000/udp -> 192.168.178.26:12000
12001/udp -> 192.168.178.26:12001
12002/udp -> 192.168.178.26:12002
12003/udp -> 192.168.178.26:12003
12004/udp -> 192.168.178.26:12004
12005/udp -> 192.168.178.26:12005
12006/udp -> 192.168.178.26:12006
12007/udp -> 192.168.178.26:12007
12008/udp -> 192.168.178.26:12008
12009/udp -> 192.168.178.26:12009
12010/udp -> 192.168.178.26:12010
12011/udp -> 192.168.178.26:12011
12012/udp -> 192.168.178.26:12012
12013/udp -> 192.168.178.26:12013
12014/udp -> 192.168.178.26:12014
12015/udp -> 192.168.178.26:12015

[Folaht]

The only way to connect to rootless containers from the outside is with forwarded ports. Rootless users have simply no privileges to create interfaces routing rules on the host.

If you want to get more security with root containers look into the --userns=auto option

I read it and just to be sure.
Does it mean that the container is not run by root, but instead a user and group called containers with a random ID (uID & gID) for such user and group is created for it?
And another question. Is this unique for each container or will all containers be run under the containers user and group?

[Luap99]

No user/group is created. Podman will use the entry is /etc/subuid and subgid to know what ids it can use. It should automatically pick the right amount of needed ids for each image and based on that create a unique id mapping for all containers. So if you look from the host all container processes run with different uids but inside the container they all use 1000 (or whatever user is set) for example.

[Folaht]

I see. And subuid/subgid are I assume ids owned by another user/group?

[folaht@Rezosur-uq rootnode-ipv6]$ cat /etc/subuid
folaht:10000:65536
[folaht@Rezosur-uq rootnode-ipv6]$ cat /etc/subgid
folaht:10000:65536

In this case myself.

Does that mean I can use sudo without the container being owned/running as root?

Is --userns=auto preferred over --userns=keep-id?
I read this on https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md that if one wants to run the app as a non-root user, which is what I want, I must use keep-id.
Is that still true

The only way to connect to rootless containers from the outside is with forwarded ports.

[rhatdan]

Running with --auto=userns in rootless mode, means that you get very few UIDs, whereas it is much larger when run in rootfull mode.

[Folaht]

With so many root non-root options, I'm now thoroughly confused what rootless mode means.

Is running the container without sudo or as root rootless mode?
Is running the app inside the container as non-root rootless mode?
Is running the container with sudo but using userns=auto also rootless, because a different uid is used for running the container? Or that considered rootfull, yet more secure and kind of semi-rootless?

I was assuming it was the former.

Is the tutorial still relevant by the way https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md, or does it need updating? I assume slirpnet4ns can be replaced by netavark?

[Folaht]

Problem solved.
I apparently removed the --ip option due to another issue and forgot.