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

The chroot Technique – a Swiss army multitool for Linux systems

livesys.se

Post reply on HN
Print view View original

31–40 of 123 posts

Re: The chroot Technique – a Swiss army multitool for Linux systems

#31

Post by mytailorisrich »

alphazard wrote: post #25
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces. A linux-naive developer would expect to spawn a new process from a payload with access to nothing. It can't see other processes, it has a read only root with nothing in it, there are no network devices, no users, etc. Then they would expect to read documentation to learn how to add things to the…

I believe this is because on POSIX systems the only way to create a new process is fork().

Re: The chroot Technique – a Swiss army multitool for Linux systems

#33

Post by rootnod3 »

alphazard wrote: post #25
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces. A linux-naive developer would expect to spawn a new process from a payload with access to nothing. It can't see other processes, it has a read only root with nothing in it, there are no network devices, no users, etc. Then they would expect to read documentation to learn how to add things to the…

That is pretty much what jails are in FreeBSD, especially thin jails.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#35

Post by goku12 »

duped wrote: post #15
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

what would "better chroot" do?

I'm not GP, but if I were to hazard a guess, they want something more than just mount space isolation. Something akin to BSD jails, without the bells and whistles of OCI containers like overlay filesystem, network virtualization, resource management, etc.

That requirement is pretty legitimate, since its easier and suitable enough for many applications for which we currently use OCI containers. For example, isolated builds, development environments, sandboxes etc. (I have an isolated build tool for Gentoo).

But Linux already has multiple solutions that fit the bill, like systemd-nspawn, LXC, bubblewrap, etc. Too bad, they aren't as widely known as chroot.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#36

Post by masom »

nesarkvechnep wrote: post #8
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

Come to FreeBSD, we have just that - jails.

yup! FreeBSD jails are essentially what OP wants with chroot++.

I was pretty puzzled when Docker and LXC came around as this whole new thing believed to have "never been done before"; FreeBSD had supported a very similar concept for years before security groups were added in Linux.

Jails and ezjail were stellar to make mini no-overhead containers when running various services on a server. Being able to archive them and expand them on a new machine was also pretty cool (as long as the BSD version was the same.)

Re: The chroot Technique – a Swiss army multitool for Linux systems

#37

Post by amstan »

mycall wrote: post #32

Is there already a wrapper utility to automate all of this process laid out in the article?

There is!

arch-chroot [1], despite its name pretty much does all the `mount -t proc` stuff the post says. It's also available on other distros like debian [2]. I have used it in the past to chroot into fedora as well.

[1] https://man.archlinux.org/man/arch-chroot.8 [2] https://packages.debian.org/arch-install-scripts

Re: The chroot Technique – a Swiss army multitool for Linux systems

#39

Post by duped »

alphazard wrote: post #25
dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces. A linux-naive developer would expect to spawn a new process from a payload with access to nothing. It can't see other processes, it has a read only root with nothing in it, there are no network devices, no users, etc. Then they would expect to read documentation to learn how to add things to the…

> Instead there is this elaborate ceremony where the principal process basically spawns another version of itself endowed with all the same privileges and then gives them up

The flags to unshare are copies of clone3 args, so you're actually free to do this. There's some song and dance though, because it's not actually possible to exec an arbitrary binary will access to nothing.

But I think the big discrepancy is that there is inherently a two step process to "spawn a new process with a new executable." Doesn't work that way - you clone3/fork into a new child process, inheriting what you will from the parent based on the clone args/flags (which could be everything, could be nothing), do some setup work, and then exec.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#40

Post by duped »

goku12 wrote: post #35
duped wrote: post #15

Earlier quoted context omitted.

what would "better chroot" do?

I'm not GP, but if I were to hazard a guess, they want something more than just mount space isolation. Something akin to BSD jails, without the bells and whistles of OCI containers like overlay filesystem, network virtualization, resource management, etc. That requirement is pretty legitimate, since its easier and suitable enough for many applications for which we currently use OCI containers. For example, isolated b…

None of those things do what chroot does but many of them involve chroot - so I'm still not grasping what "better chroot" is, other than "not chroot, but something completely different."

It sounds like people want "better exec"

Post reply on HN