Creating a mount namespace and using pivot_root seems like a safer solution.
I don’t think pivot_root is necessary for something like this, but a new mount namespace will definitely help avoid creating a mess on accident
The chroot Technique – a Swiss army multitool for Linux systems
41–50 of 123 posts
Re: The chroot Technique – a Swiss army multitool for Linux systems
#42I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.
As a number of comments have noted, there are a bunch of different axes that chroot could be 'better' on - e.g. security and sandboxing.
I wrote https://github.com/aidanhs/machroot (initially forked from bubble wrap) a while ago to lean into the pure "pretend I see another filesystem" aspect of chroot with additional conveniences (so no security focus). For example, it allows setting up overlay filesystems, allows mounting squashfs filesystems with an overlay on top...and because it uses a mount namespace, means you don't need to tear down the mount points - just exit the command and you're done.
The codebase is pretty small so I just tweaked it with whatever features I needed at the time, rather than try and make it a fully fledged tool.
(honestly you can probably replicate most of it with a shell script that invokes unshare and appropriate mount commands)
Re: The chroot Technique – a Swiss army multitool for Linux systems
#43Earlier quoted context omitted.
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"
One annoying part of using chroot if you're creating them on the fly is teardown - you have to manually invoke umount, and also take care to get this right for partially created chroots (maybe you detected an error after mounting proc, in the process of getting other files in place).
This was my original motivation in creating machroot (mentioned elsewhere in this thread) and having it use namespaces.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#44Earlier quoted context omitted.
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 a…
this whole new thing believed to have "never been done before";
Nobody with knowledge of sandboxing believed this, Virtuozzo and later OpenVZ had been on Linux for a long time after all. Virtuozzo was even from a similar time frame as FreeBSD jails (2000-ish).
The key innovation of Docker was to provide a standardized way to build, distribute, and run container images.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#45Is there already a wrapper utility to automate all of this process laid out in the article?
In addition to the other comments: If you are on NixOS, you can use nixos-enter [1].
Re: The chroot Technique – a Swiss army multitool for Linux systems
#46I 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…
> a read only root with nothing in it
A lot of things break if there's no /proc/self. A lot more things break if the terminfo database is absent. More things break if there's no timezone database. Finally, almost everything breaks if the root file system has no libc.so.6.
When you write Dockerfiles, you can easily do it FROM scratch. You can then easily observe whether the thing you are sandboxing actually works.
> no users
Now you are breaking something as fundamental as getuid.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#47Earlier quoted context omitted.
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().
There is the later added posix_spawn, which could be implemented with a system call, even if on Linux it is emulated with clone + exec.
posix_spawn can do much, but not all, of what is possible with clone + exec. Presumably the standard editors have been scared to add too complex function parameters for its invocation, though that should not have been a problem if all parameters had reasonable default values.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#48chroot was (is?) the recommended way of installing gentoo which is pedagogical.
There are various handy (chroot) techniques that are probably considered "old school" now. For example, having a "rescue partition" which can be booted into remotely, and from there reinstall or repair the "main os". This is necessary when repartitioning remotely, for example.
Re: The chroot Technique – a Swiss army multitool for Linux systems
#49I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.
I built https://github.com/jrz/container-shell as a simple chroot on docker. I use it for both development and sandboxing.
Besides that I have a simple script that starts an ephemeral docker with debian-full + tools.
I also have some scripts that leverage macOS's 'sandbox-exec'
Re: The chroot Technique – a Swiss army multitool for Linux systems
#50chroot was (is?) the recommended way of installing gentoo which is pedagogical. There are various handy (chroot) techniques that are probably considered "old school" now. For example, having a "rescue partition" which can be booted into remotely, and from there reinstall or repair the "main os". This is necessary when repartitioning remotely, for example.
That’s still how most Linux OS installers install. They just do that for you.
It’s still used for recovery but recovery partitions have kinda gone out of fashion as the ability to consistently boot has gotten better. Additionally, thumb drives and net boot make the partition a little less necessary.