Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Podman: A Daemonless Container Engine

podman.io

Post reply on HN
Print view View original

111–120 of 250 posts

Re: Podman: A Daemonless Container Engine

#111

Post by 8fingerlouie »

lima wrote: post #70
SEJeff wrote: post #41

Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster: https://github.com/containers/crun

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

Contrary to popular belief, memory safe C is possible to write, and with modern linters it’s even easier.

Yes it’s easier to shoot yourself in the foot, but with practice you can learn to miss every time.

Re: Podman: A Daemonless Container Engine

#112

Post by yobert »

yobert wrote: post #109

I've been trying to use podman in production and it is not working very well. I'm excited for this technology but it is not ready. - podman layer caching during builds do not work. When we switched back to docker-ce, builds went from 45 minutes to 3 minutes with no changes to our Dockerfile - fuse-overlayfs sits at 100% CPU all day, every day on our production servers - podman loses track of containers. Sometimes the…

Reading through the comments though it looks like I should try making a BTRFS mount for the container storage and that might help the fuse-overlayfs problems though.

Re: Podman: A Daemonless Container Engine

#113

Post by edwintorok »

stuaxo wrote: post #30
edwintorok wrote: post #4

Earlier quoted context omitted.

If you run it as non-root it is significantly slower than docker as root. Docker can us the overlay2 kernel driver, whereas podkan would use fuse-overlayfs in userspace. This has a high CPU overhead (e.g. don't try to run AFL inside podman), and a 1024 FD limit for the entire container (so a 'make -j40' usually dies). There are ways around it: raise the ulimit for your user and run new enough podman to raise limit fo…

Are these fuse limitations or fuse-overlayfs limitations ?

I think FUSE limitations: fuse is served by a single userspace process, which is limited the same way as any other userspace process by ulimit. It is not a fundamental limitation of podman, just of podman's default rootless behaviour.

Re: Podman: A Daemonless Container Engine

#114

Post by chippiewill »

dathinab wrote: post #15
shyim wrote: post #7

I still miss an easy way to setup multiple containers in a single network like with docker-compose. podman-compose is not really useable.

You can use docker-compose with podman. Through it has similar drawbacks as using docker-compose with docker. As far as I know there is currently no rootless way on Linux to setup custom internal networks like docker compose does (hence why podman-compose doesn't support such things).

There definitely is a way as creating custom networks works perfectly fine with rootless docker. I'm surprised if podman doesn't support that since it uses rootlesskit (same as rootless docker) which does the heavy lifting for rootless networking.

Re: Podman: A Daemonless Container Engine

#115

Post by 8fingerlouie »

superbcarrot wrote: post #108

Can anyone explain what daemonless means in this case and what the advantages are? (I don't work in this space and my knowledge ends with knowing what a container is.)

IIRC, docker by default runs a daemon as root, which spawns all your containers. It is possible to run it rootless as well (https://docs.docker.com/engine/security/rootless/), though you’d need a separate daemon for each user you’d want to run containers as.

Podman doesn’t have that. It spawns containers without the help of a controlling daemon, and can spawn containers both as root and rootless.

Rootless is of course a fairly big deal considering if you run docker containers as root, and runc has a vulnerability, you could potentially escape the container and become root, where a rootless installation would just let you escape to whatever user is running the container.

Re: Podman: A Daemonless Container Engine

#116

Post by MaxBarraclough »

SEJeff wrote: post #98
lima wrote: post #90

Earlier quoted context omitted.

Better, yes. Safe, no. Even with ASAN and modern C++, vulnerabilities happen all the time.

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

The Linux kernel still has memory safety issues to this day.

The C++ approach is to offer a feature-rich language so the programmer doesn't have to reinvent common abstractions. The C approach is to offer a minimal and stable language and let the programmer take it from there. It's not obvious a priori which approach should result in fewer memory safety issues. If I had to guess my money would be on C++ being the better choice, as it has smart pointers.

Re: Podman: A Daemonless Container Engine

#117

Post by coder543 »

SEJeff wrote: post #98
lima wrote: post #90

Earlier quoted context omitted.

Better, yes. Safe, no. Even with ASAN and modern C++, vulnerabilities happen all the time.

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

Saying C is easier to secure than Modern C++ is just confusing. The point of a lot of recent C++ features is to make memory safety easier to achieve. I personally don't think it gets anywhere close to safe enough for me to recommend, when Rust is such a competent option that people can choose instead. I would still rather people have the tools of C++ at their disposal instead of having to do everything themselves in C.

Please find me a well-known C code base that doesn't suffer from memory safety CVEs. You're the one making the claim that they exist... I can't prove that such a thing doesn't exist, but I can point to how curl[0][1], sqlite[2][3], the linux kernel[4][5], and any other popular, respected C code base that I can think of suffers from numerous memory safety issues that memory safe languages are built to prevent.

Writing secure software is hard enough without picking a memory unsafe language as the foundation of that software.

"Just find/be a better programmer" isn't the solution. We've tried that for decades with little success. The continued prevalence of memory safety vulnerability in these C code bases shows that existing static analysis tools are insufficient for handling the many ways that things can go wrong in C.

I think you mentioned railcar elsewhere in this thread, and I would find it easier to be interested in a runc alternative that is written in a memory safe language... which railcar is.

[0]: https://curl.se/docs/CVE-2019-5482.html

[1]: https://curl.se/docs/CVE-2019-3823.html

(among numerous others)

[2]: https://www.darkreading.com/attacks-breaches/researchers-sho...

[3]: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=SQLite

(the second link has quite a few memory safety issues that are readily apparent, including several from SQLite that affected Chrome)

[4]: https://www.cvedetails.com/cve/CVE-2019-11599/

[5]: https://www.cvedetails.com/cve/CVE-2018-15471/

Re: Podman: A Daemonless Container Engine

#118

Post by tshtf »

8fingerlouie wrote: post #111
lima wrote: post #70

Earlier quoted context omitted.

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

Contrary to popular belief, memory safe C is possible to write, and with modern linters it’s even easier. Yes it’s easier to shoot yourself in the foot, but with practice you can learn to miss every time.

It probably isn't worth trying.

djb wrote remotely exploitable C for qmail, applications written by the OpenBSD team have had exploitable memory issues, Microsoft still doesn't get it right, neither do Linux kernel devs.

Re: Podman: A Daemonless Container Engine

#119

Post by tene »

eeZah7Ux wrote: post #93
jnwatson wrote: post #86

Earlier quoted context omitted.

There's also the copious amount of static analysis and warnings built into gcc and clang these days, not to mention safer build options. Writing C today is quite a bit better than even 10 years ago.

External static analyzers also improved a lot. You can ensure memory-safety in C by enforcing strict rules since the first commit.

Can you share any good examples of C codebases that have enforced these rules and successfully avoided having memory safety problems? Can you share any details on what rules a team could use to reliably avoid having memory safety problems when writing C?

Re: Podman: A Daemonless Container Engine

#120

Post by [deleted] »

lima wrote: post #70
SEJeff wrote: post #41

Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster: https://github.com/containers/crun

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

[deleted]
Post reply on HN