Live data from Hacker News

Podman: Pasta User-Mode Networking

github.com

21–28 of 28 posts

Re: Podman: Pasta User-Mode Networking

#21
post #19

Earlier quoted context omitted.

I have a project that relies on user mode networking. passt is a very welcome development. Really hoping it supports Windows QEMU hosts at some point.

Very difficult, it's not portable so it would be basically a rewrite. I read that similar APIs are present in FreeBSD, but at least it's POSIX-based so that does not really say anything about the complexity of a Windows port. Anyhow, the presentation mentioned above explains which Linux extensions are needed.

You might be right, but I hope you're not. :)

I had a look at Winsock documentation a while ago, that doesn't look so bad in terms of what we need. See also: https://lore.kernel.org/qemu-devel/20220919232441.661eda8d@e.... Replacing epoll might be messy, though.

Re: Podman: Pasta User-Mode Networking

#22

My main question about this is why this instead of SLIRP? There's not really a tl;dr for that obviously on the repo? I've definitely had problems with SLIRP before but which ones does this aim to solve?

I have specifically not added that out of respect for what Slirp represented to dialup shell users in the late 1990s and for what it did for the ecosystem in the past 15 years. I used it for more than a decade myself, and if you consider that it's now used for containers and virtual machines, given the original purpose, it's really an impressive piece of software. Feature comparisons can be risky at times.

It's mostly in the direction of IPv6 support, performance, security. Those topics are covered in slides: https://static.sched.com/hosted_files/kvmforum2022/01/passt_... or recording: https://www.youtube.com/watch?v=U89bWP1HNgU of a recent talk from KVM Forum 2022.

Re: Podman: Pasta User-Mode Networking

#24
post #20

Earlier quoted context omitted.

Does it support rootless containers?

Yes, according to their GitHub page. I use it as the networking stack for Podman.

See podman-network-create(1), I think the description of the --driver option should clarify this. You can use macvlan there, but in rootless operation you don't have access to the network interface of the hosts -- unless you set that up networking separately beforehand (as root), that is.

So yes, it supports rootless, but by (kernel) design, there's no magic way to bridge (no pun intended) that gap (even with macvlan).

Re: Podman: Pasta User-Mode Networking

#25
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-g…

Thanks. I didn't understand what you mean that Podman would obscure the value of the client IP?

Re: Podman: Pasta User-Mode Networking

#26

Earlier quoted context omitted.

> 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-g…

Thanks. I didn't understand what you mean that Podman would obscure the value of the client IP?

There are two port forwarding modes allowed with slirp4netns. One uses slirp4netns itself: data is passed across a tap device, libslirp translates the destination address and preserves the source address.

The second one uses rootlesskitport (while slirp4netns still takes care of outbound connections): it opens sockets directly in the detached network namespace and passes data between sockets without going through the tap device. It's faster, because you avoid 1. the tap device 2. Layer-4/Layer-2 translations. But those sockets are local to the namespace, so destination and source address become loopback addresses. That might be unexpected in some cases, see also https://nvd.nist.gov/vuln/detail/CVE-2021-20199.

pasta implements both modes (it's the "tap bypass" in https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...), and selects the appropriate one based on the original source address, so that you don't need to choose one. Local connections skip the tap device, non-local ones go through it (you can have non-loopback source addresses only for traffic coming through a a non-loopback interface).

Re: Podman: Pasta User-Mode Networking

#27
post #26

Earlier quoted context omitted.

Thanks. I didn't understand what you mean that Podman would obscure the value of the client IP?

There are two port forwarding modes allowed with slirp4netns. One uses slirp4netns itself: data is passed across a tap device, libslirp translates the destination address and preserves the source address. The second one uses rootlesskitport (while slirp4netns still takes care of outbound connections): it opens sockets directly in the detached network namespace and passes data between sockets without going through the…

Ah OK, that make sense. Slirp4netns and Past both seem pretty interesting. I'm looking forward spending some time with Podman networking. Cheers.

Re: Podman: Pasta User-Mode Networking

#28

As an opensource lover, you gotta appreciate redhat registering a "containers" organisation with rh-only maintained projects. True OSS philosophy at work here!

that's a "non issue" - commercial companies are vendor-locked with cloud on conscious decision so it doesnt matter - they pay for everything (an sometimes multiple times),

and any orgs that treasure open source philosophy either forking or not touching anything of redhat with a long pole.

Post reply on HN