61–70 of 123 posts
> sudo mkdir /rescue/boot > sudo mount /dev/nvme0n1p3 /rescue/boot This is a little extra. What you can generally do is immediatelly after chroot just run 'mount -a' to mount everything from the chroot's fstab. The empty `/boot` probably already exists.
Sure, chroot can be useful in a pinch, but it would not be the first thing I'd reach to. If you got the partitions mounted, you can already do quite a lot of things without needing to chroot.
Just looked and it looks like "Recovery Is Possible" hasn't been updated in a dozen years which dates my story, but I fondly remember overnight phone calls from panicked new sysadmins and telling them to be calm and "RIP it and get chrooted in" and then waking up to help them troubleshoot.
With qemu-user and binfmt you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC to fix a hacking session gone wrong. Though these days you may want to look into things like systemd-nspawn instead of plain chroot.
systemd-nspawn --directory /tmp/rescue --boot -- --unit rescue.target
It should automatically find the boot partition and mount it as well.
Earlier 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…
> 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. > n…
> no users
I mean running as root. I think all processes on Linux have to have a user id. Anything inside a sandbox should start with all the permissions for that environment. If the sandbox process wants to muck around with the users/groups authorization model then it can create those resources inside the sandbox.
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()++.
Shame Plan9 blew its weirdness budget.
With qemu-user and binfmt you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC to fix a hacking session gone wrong. Though these days you may want to look into things like systemd-nspawn instead of plain chroot.
This sounds very interesting! What's the scenario where you'd do this? Would you be, for example, emulating an ARM processor with qemu on an x86 computer and chrooting into Android on an eMMC?
With qemu-user and binfmt you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC to fix a hacking session gone wrong. Though these days you may want to look into things like systemd-nspawn instead of plain chroot.
> you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC This sounds very interesting! What's the scenario where you'd do this? Would you be, for example, emulating an ARM processor with qemu on an x86 computer and chrooting into Android on an eMMC?
Creating a mount namespace and using pivot_root seems like a safer solution.
This brings back memories - I owned a large web hosting company and we had thousands of machines. When hardware issues came up, or machines wouldn't boot, using this method was our first line of defense - we'd boot the machine from a burned copy of "Recovery Is Possible" which was an all-in-one Linux distro for recovery, then mount the partitions and chroot in to figure out what is going on - or use rsync to migrate…