I can highly recommend: https://github.com/fsquillace/junest
The chroot Technique – a Swiss army multitool for Linux systems
21–30 of 123 posts
Re: The chroot Technique – a Swiss army multitool for Linux systems
#22I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.
We kind of did but its all put in the context of containers. Check out the unshare command.
unshare --mount
Most examples you'll find put it in the context of containers, like https://www.redhat.com/en/blog/mount-namespaces
Re: The chroot Technique – a Swiss army multitool for Linux systems
#23I 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.
Or DragonFlyBSD with vkernels
Re: The chroot Technique – a Swiss army multitool for Linux systems
#24The tools shouldn't require the use of chroot. It is quite common on Solaris to be able to specify a path that should be considered the root directory for the tool, usually -R. This was super useful in a netboot world using nfs, and also for crash recovery.
If a system is screwed up enough, then a chroot strategy won't work because it relies on the path you are chrooting to to be generally valid and functional. If it's missing libraries you may well be screwed.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#25I 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 sandbox. They want to pass in a directory, or a network interface, or some users. The effort goes into adding resources to the sandbox, not taking them away.
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, hopefully leaving itself with only the stuff it wants the sandboxed process to have. Make sure you don't forget to revoke anything.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#26I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.
Docker is not using chroot in any way. Escaping chroot is only a matter of calling chdir('..') and poof, you are out of the "sandbox"
Re: The chroot Technique – a Swiss army multitool for Linux systems
#27Re: The chroot Technique – a Swiss army multitool for Linux systems
#28Creating a mount namespace and using pivot_root seems like a safer solution.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#29The arch linux install has a little wrapper around chroot, used to configure the installed system without booting it. https://wiki.archlinux.org/title/Installation_guide#Chroot
Gentoo’s stage3 would like to say a word
I remember first installing Gentoo…printed the whole manual and followed along. After a failed attempt and second successful install I learned enough to know that I could use a LiveUSB of my choosing and chroot into the install. Good times!