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

Linux containers in a few lines of code

zserge.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Linux containers in a few lines of code

#81

Post by kelnos »

cyphar wrote: post #69
streb-lo wrote: post #19

Anyone want to chime in on why pivot_root is preferable to a chroot jail? It's kind of hand-waved in the article.

This is mostly to do with the implementation of chroot(). Because it only applies to a single process (and mount tables are per mount namespace), it was implemented in such a way that directories above the root of the chroot are still technically accessible (the mounts above the root directory are still present in the mount hierarchy). This results in all sorts of fun bugs where if you chroot() inside a chroot() you…

> though sadly sometimes chroot() is needed because pivot_root() doesn't work on initramfs.

Are people actually attempting to boot a super-minimalist system that just has a kernel and an initramfs with something like docker into it where they don't bother with a rootfs at all and just start running containers directly from the initramfs? That's kinda cool, if that's the case.

Re: Linux containers in a few lines of code

#82

Post by fulafel »

alexchamberlain wrote: post #57
mmastrac wrote: post #37

Big caution here. Do NOT use this style of code to invoke ip tools. This was the cause of a huge number of security vulnerabilities on Android in the first few years. Even if you're hardcoding interfaces to start, it's likely someone else will drive by later on and replace one of the args with %s. > system("ip link add veth0 type veth peer name veth1"); Always, always, always use exec*() APIs.

Are there not better C APIs to call that `ip` et al are wrapping?

They are low-level APIs, so strictly worse for the purpouse.

Re: Linux containers in a few lines of code

#83

Post by cyphar »

kelnos wrote: post #81
cyphar wrote: post #69

Earlier quoted context omitted.

This is mostly to do with the implementation of chroot(). Because it only applies to a single process (and mount tables are per mount namespace), it was implemented in such a way that directories above the root of the chroot are still technically accessible (the mounts above the root directory are still present in the mount hierarchy). This results in all sorts of fun bugs where if you chroot() inside a chroot() you…

> though sadly sometimes chroot() is needed because pivot_root() doesn't work on initramfs. Are people actually attempting to boot a super-minimalist system that just has a kernel and an initramfs with something like docker into it where they don't bother with a rootfs at all and just start running containers directly from the initramfs? That's kinda cool, if that's the case.

You could do that (though one could argue that there's no real benefit to using containers in that case), but the issue is sadly more general than that. You cannot use pivot_root() if the current root is on initramfs. The reason is fairly historic, and boils down to "you cannot unmount initramfs" in the same way that "you cannot kill pid1".

This means that setups where you have the entire OS image in initramfs, and you try to run a container (even if it has a different filesystem as its rootfs) it will fail with pivot_root(). There are solutions for this but they require changing how the system is started (which can be a bit complicated depending on what system you're using to build your initramfs). From memory, minikube has used --no-pivot-root for a while precisely for this reason, though I believe they have switched away from it sometime recently.

Re: Linux containers in a few lines of code

#84

Post by koffiezet »

Spivak wrote: post #17
dmayle wrote: post #4

A little bit of education about container systems in linux[1]. A container system is typically made up a number of components: isolation layer : the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers) raw container configuration : Given an image and some metadata (like cpu limits), launc…

I feel like podman is proving that you don't really need the api daemon and a porcelain over runc with a one-off process supervisor is sufficient for a good number of workloads. Being able to run containers like any other process and leave the lifecycle management to systemd is actually really nice.

There are imho 3 key features what made Docker great:

* the combination of all technologies touched here in the example, but it's missing a very important-one: the layered filesystem

* A defined packaging format and way of distributing images

* Having an API to talk to these things easily.

That is what kickstarted and revolutionised the container space, but there were still many technology gaps and questions. They tried to put everything in one single tool, which was a double-edged sword I think: it made usage easy which accelerated adoption, but also caused it being a big 'monolith' project, which is a bit ironic given that it ended up being extremely suitable for micro-service architectures.

For me as an early adopter, it was very clear from the start that the main problem was how do you actually deploy this in production. Docker saw a very large part of the conceptual bigger picture, but they had any clue how to address this, but to be fair, very few did.

Right now, a lot of lessons have been learned, and standards have been created in the container space.

Nowadays, for production loads, k8s has become the de-facto standard container api, and Docker itself doesn't really carry that much weight anymore, the runtime itself isn't important anymore. It being podman, runc, or still a full-blown docker? I couldn't really care less. Docker's stronghold will remain the development environment for a while though, just due to the massive amount of resources and easy to use solutions out-there...

Re: Linux containers in a few lines of code

#85

Post by josteink »

sp332 wrote: post #14
throwaway55554 wrote: post #8

Earlier quoted context omitted.

I don't know, I find "Linux Containers" to be sufficiently generic as Linux has native support for them. LXD/LXC, Docker, etc, are simply tools built upon that.

I agree. Most people who read "Linux Containers" are going to think of Docker, not LXD.

People are different.

When I think about containers, I think about isolated system images, lightweight VMs, which I can use and adapt to solve a problem at hand.

When I hear Docker, I think about static, locked-down application-images made by others, to deploy in the cloud, which I'm not given to adapt to my needs, and I also think about things which is not natively integrated into my Linux-distro and for which I will have to provide glue manually. I also think about a startling amount of complexity in a new stack which I would have to learn, just to manage what is actually really just basic Linux-systems.

While all that may or may not be true, that's what I think about when I hear "Docker".

Hearing "containers" on the other hand, makes me happy. And yeah, I'll got with LXC/LXD any day.

Re: Linux containers in a few lines of code

#87

Post by rdslw »

uvuv wrote: post #63
mehrdadn wrote: post #20

Could someone comment on how secure such a container is, at least nominally? Should I be able to theoretically run untrusted code on such a container if the system is bug-free and I add proper error-checking to the code? Or are there things that you'd need to worry about the code being able to access? Any considerations regarding sudo permissions?

Definitely not secure. The author did a great job explaining container runtimes in basic terms, but there's a lot of security features missing. Mainly: * Reducing the container's capabilities * Restricting access to resources through cgroups * Applying seccomp filters to prevent certain syscalls. As another comment suggested, user namespaces are another hardening feature, but not all container runtimes enable it by d…

Thank you for detailed answer and interesting links!

Could you please explain/point me to some information/source, why docker can't use -net=host namespace if userns is enabled, while on the other hand rootlesskit[1] which uses userns by default, dont have problem with using host netns (--net=host) ?

[1] https://github.com/rootless-containers/rootlesskit

Post reply on HN