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

41–50 of 87 posts

Re: Linux containers in a few lines of code

#41

Post by rantwasp »

throwaway8941 wrote: post #35
lmuench wrote: post #27

Earlier quoted context omitted.

Can you point me to some online resources? I'd like to learn more about this.

https://lwn.net/Articles/324291/ https://lwn.net/Articles/325369/ https://lwn.net/Articles/327738/

nice. thank you

Re: Linux containers in a few lines of code

#42

Post by mehrdadn »

jeffbee wrote: post #38
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?

Big “if”. There has never, in thirty years, been a Linux that lacked a user-to-root privilege escalation path. Running untrusted code in containers is the same as it’s ever been: totally unsafe. VMs are safer, or, minimally, ptrace sandboxes intercepting all syscalls.

Are you saying because of bugs or are you saying it's by design? I explicitly said ignore OS bugs.

Re: Linux containers in a few lines of code

#44

Post by jacobr1 »

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.

Yep. Because the use case that seems to be most common is not running untrusted containers, but rather something more like static compilation, but with ruby or javascript code. So on a single machine just considering it another process, but with better isolation of dependencies is (including encapsulation of distinct processes and in-container network activity) is actually the use case. And once we scale up to multiple machines for resource needs, something like k8s starts to make sense, because it just moves the abstraction to the cluster level rather than the machine. The more you get k8s to be a "cluster systems" the saner the management.

Re: Linux containers in a few lines of code

#46

Post by jeffbee »

mehrdadn wrote: post #42
jeffbee wrote: post #38

Earlier quoted context omitted.

Big “if”. There has never, in thirty years, been a Linux that lacked a user-to-root privilege escalation path. Running untrusted code in containers is the same as it’s ever been: totally unsafe. VMs are safer, or, minimally, ptrace sandboxes intercepting all syscalls.

Are you saying because of bugs or are you saying it's by design? I explicitly said ignore OS bugs.

Yes you did, but that’s as useless as a discussion based on ignoring the laws of thermodynamics.

Re: Linux containers in a few lines of code

#47

Post by jeffbee »

mmastrac wrote: post #43
jeffbee wrote: post #39

Linux containers in one shell statement $ echo $$ > tasks

I'm not sure if this is serious or a joke, but can you explain it further?

Given certain initial conditions, this statement moves the current process (and any process it subsequently creates) into a control group, which meets minimal definitions of containerization.

Re: Linux containers in a few lines of code

#48

Post by freedomben »

throwaway8941 wrote: post #34
freedomben wrote: post #33

Earlier quoted context omitted.

Could not agree more. As a Fedora user I was mildly intrigued when Podman showed up, I played with it briefly but stopped because most of my projects used docker-compose, which doesn't work with Podman. When I went to work at Red Hat I decided to really try Podman, and I love it now. Once I discovered that Podman supports Kubernetes Pods (same YAML and all) I realized how clunky docker-compose actually is. Since most…

podman-compose works fine for me, despite being advertised as "still under development". https://github.com/containers/podman-compose

Thanks, it might be time for me to give it another try.
Post reply on HN