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

101–110 of 123 posts

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

#101

Post by samuell »

jimmaswell wrote: post #77

I just installed Gentoo from WSL2 this way, on my secondary NVME on my Framework 16. Went without a hitch besides some minor things you need to be aware of: -the lack of access to efi subsystem from wsl means you need to pass some extra flags to help grub/etc along, and you may need to set it as the boot partition in the bios manually -you'll have to mount the drive to wsl with `wsl --mount --bare`, after finding the…

That's pretty incredible, that it works from Windows too!

Now I'm just wondering if it would work from a Linux running in the browser, accessing the USB through WebUSB ;D

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

#102

Post by dev_hugepages »

gerdesj wrote: post #88
jimmaswell wrote: post #78

Earlier quoted context omitted.

I use my Gentoo installation usb when this comes up

System Rescue used to be Gentoo based and then switched to Arch. You can install both Arch and Gentoo with SR and obviously you can install Arch with a Gentoo install CD and vice versa. SR also has some rather handy SAM database editing facilities. Mount Windows at /mnt and then enable and reset the Administrator password. Jolly handy for getting super duper user access on a Windows box. Its been a while since I inst…

Yes, they do have such script.

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

#103

Post by teddyh »

IshKebab wrote: post #66
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()++.

Plan9 had a proper solution for this. New processes don't get access to any files by default - you have to explicitly mount directories for them, capability style. Shame Plan9 blew its weirdness budget.

It has nothing to do with weirdness; Unix itself was plenty weird for its time. The relevant difference between Unix™ and Plan 9 is that Unix source code was given away (or cheaply licensed) to hardware companies which all wrote their own operating systems on top (SunOS, Ultrix, HP-UX, etc. etc.). This made Unix the common factor of very many commercial workstation environments. Plan 9? It was sold directly as a commercial product, for no hardware platform in particular. Nobody wanted to buy it.

People liked Unix because it was free – either really free, via BSD, or as a Unix derivative provided at no cost when people bought their workstations. A new revolutionary operating system had absolutely no reason for anybody to buy it: No commercial developers wanted to develop to a platform without users, and no users wanted a platform without software.

Plan 9 only changed their license many years later, when it was too late for anybody to care, and Unix had become the established standard.

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

#104

Post by fsniper »

benou wrote: post #74
thatcherc wrote: post #67

Earlier quoted context omitted.

> 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?

Here is an example of preparing a debian ARM image on x86 with debootstrap, qemu and chroot: ~# sudo apt install qemu-user-static debootstrap ~# mkdir /tmp/arm ~# debootstrap --foreign --arch=armhf buster /tmp/arm http://deb.debian.org/debian ~# cp /usr/bin/qemu-arm-static /tmp/arm/usr/bin/ ~# chroot /tmp/arm # from that point, you're running ARM! ~# /debootstrap/debootstrap --second-stage

This is very cool! I had no idea you could chroot into different architectures.

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

#105

Post by alfiedotwtf »

foresto wrote: post #58
alphazard wrote: post #25

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…

> There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces. What bothers me most about sandboxing with linux namespaces is that edge cases keep turning up that allow them to trick the kernel into granting more privileges than it should. I wonder if Landlock can/will bring something more like FreeBSD jails to the table. (I haven't made time to read about…

This is why I would still rather isolate using QEMU, docker, or Virtually Box rather than a very think chroot-like environment

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

#106

Post by alfiedotwtf »

microtonal wrote: post #44
masom wrote: post #36

Earlier quoted context omitted.

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.

Virsh had worked for a long time before docker came around, but yeah… you essentially had to build your own Docker-like infrastructure that only you were using

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

#109

Post by ndsipa_pomu »

amelius wrote: post #107

What if I'm ssh'd into a Linux box and want to (say) format its root disk. Can I boot a new instance of Linux in memory and then access the root disk?

Interesting question and I don't know how you'd do that - maybe using some statically linked binaries for fdisk and mkfs. However, why would you ever want to do that? If you want to remove data from the disk, then just running a suitable "dd" command would wipe the disk. I can't think of any other use case that wouldn't subsequently involve booting from a live iso which would let you format the disk anyway.

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

#110

Post by 1oooqooq »

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()++.

ironically docker never gave you true network isolation because there's no way to make it user friendly. plus the many exploits on the all powerful daemon.

but most professional world use systemd to bootstrap isolated processes nowadays, which is kinda if what you are hinting at. cgroups2 and namespaces are what you want.

Post reply on HN