Live data from Hacker News

Podman: Pasta User-Mode Networking

github.com

1–10 of 28 posts

Re: Podman: Pasta User-Mode Networking

#2
Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?

Re: Podman: Pasta User-Mode Networking

#3
post #2

Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?

Because you want containers to be able to allocate ports that are already in use on your host. Or at least you don't want that to be a source of errors.

Re: Podman: Pasta User-Mode Networking

#4
post #2

Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?

Because you want containers to be able to allocate ports that are already in use on your host. Or at least you don't want that to be a source of errors.

On top of that, you usually want to isolate the container workload with an observable network abstraction instead of granting it full (albeit non-root) access to host network facilities (including sockets).

See https://medium.com/nttlabs/dont-use-host-network-namespace-f... for just an example of what can go wrong otherwise.

Re: Podman: Pasta User-Mode Networking

#5
post #2

Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?

SLIRP is a clever tool that turns network traffic (raw IP frames on one side) into connect(2), read, write etc system calls on the other side. eg. If it sees a virtual machine is making a connection by sending a TCP SYN packet, it will on one side turn that into a connect(2) system call, and on the other side send back the appropriate TCP packets to complete the connection. It also does ARP, DNS, etc. If you think of a kernel as something that turns socket system calls into packets, then SLIRP is the opposite.

SLIRP is mainly useful when you don't have (or don't want) root permissions to send raw packets. I may be one of the few people here to have used SLIRP back in the early 90s for its original purpose: You have dial up access to a shared SunOS terminal login, how do you turn that into a full network connection for your local Linux PC? SLIRP (+ expect, SLIP and some scripting) solved this exact problem.

Passt (https://passt.top/passt/about/) is a more modern replacement for SLIRP that amongst other things fully supports IPv6 and is more secure architecturally (runs in a separate process, uses modern Linux mechanisms for isolation etc). There was a talk about it here: https://kvmforum2022.sched.com/event/15jJY/slirp-is-dead-lon...

This pull request is using Pasta which is something on top of Passt that does something with network namespaces which I'm not entirely clear on, but some docs here: https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...

Re: Podman: Pasta User-Mode Networking

#7
This looks like a replacement for something called slirp4netns which is "User-mode networking for unprivileged network namespaces." I wasn't familiar with this or libslirp. Can someone say what the practical use-case is for User-mode networking? Is this just to complements Podman's existing security posture or something else?

Re: Podman: Pasta User-Mode Networking

#8
post #7

This looks like a replacement for something called slirp4netns which is "User-mode networking for unprivileged network namespaces." I wasn't familiar with this or libslirp. Can someone say what the practical use-case is for User-mode networking? Is this just to complements Podman's existing security posture or something else?

> Is this just to complements Podman's existing security posture

To my understanding, yes. You can run Podman containers as non-root, but containers often have their own network namespace which would require root privileges to create without slirp4netns. I don't believe there are really practical reasons to use it beyond that pretty big one. It does (used to?) incur some performance hit even (but only at some multi-gb rate and even then only a fractional penalty IIRC). e: I was thinking about rootlesskit here, which is somehow combined with slirp4netns in some cases.

I remember looking into Pasta a while back when I wanted to get client-ip-addresses in a container and the current Podman implementation for user-networks obscures that value. I think this might fix that along with IPv6 and other improvements.

Post reply on HN