0

I use Arch Linux as my primary OS and I work on a web app built for Centos. Initially I was using LXC Container in my Arch to run a Centos, however due to problems configuring Network over Wifi etc I decided to find an alternative and someone suggested that chrooting directly might work instead.

Currently I just use LXC commands to create a Centos and just chroot into it and work. I also mount the /bind, /proc and /sys into my chrooted environment. My web app works just fine with no problems.

Are there any concerns/caveats in this approach? I still haven't tried advanced things like Java JVM yet. I know it uses the host system's Kernel, and I guess System Calls are backward compatible in Linux (which is why this idea works), so everything should work as seamless as you would expect.

Still I would like to know if there are scenarios where you could get into problems using chroot? Like are there any scenarios where chroot might not work like a normal system? Logically I can't see anything as long as Kernels are backward compatible. The one place I can think of is when the Host system's Kernel has a different implementation compared to original Kernel and if there are bugs in that which is usually unlikely.

While I use Arch, I would like to get a general perspective. My main idea is to recommend this to my colleagues who don't use Centos as their primary OS due to various reasons. There are also use cases where you need a 32-bit machine on a 64-bit. Lot of them spent a lot of time setting up VM's etc but is that really needed for a Linux on a Linux "virtualization"? I personally feel chroot is awesome and not just a debugging tool, however I wanted to get some expert opinion.

Nishant
  • 603
  • 1
    If you are using arch-chroot instead of chroot, there are "issues" with the pid namespace. You might also want to look at systemd-nspawn. – StrongBad Aug 30 '16 at 17:47
  • I just use the normal chroot even on Arch. For 32-bit containers I do linux32 chroot <path-to-root> – Nishant Aug 30 '16 at 17:53
  • 1
    You might want to look at docker - allows you to easily create containers with networking or vagrant - to easily configure fully fledged development VMs locally. Both of these work excellently in a dev environment and you can easily share the configurations with your colleagues - they are both designed to solve the problem you have, developing an application against one distro on any other distro (even when on osx and windows with vagrant) – Michael Daffin Aug 30 '16 at 18:49
  • Yeah but if chroot does all that, isn't Docker an overhead? Docker and LXC seems to be chroot on steroids, sharing the host kernel. I couldn't see what additional value Docker can bring in (I am a fan of minimalism xD), however I guess I need to research on that. OSX and Windows support with Vagrant is something that seems interesting to explore. I would be happy if I can help those users as well. – Nishant Aug 30 '16 at 19:25

2 Answers2

2

Chroot is not a container, it just changes the view of the filesystem. Network is still the same, devices are still the same, pids are still the same, uids are still the same, root is still root.

This means that actions taken in a chroot can afect the wider system. If you start a daemon in the chroot and it binds to a port then it will occupy that port on the entire system, not just in the chroot. If you (or a script) uses killlall in a chroot it will kill processes outside the chroot as well.

In particular installing/upgrading packages in a chroot can lead to daemons beind started inadvertantly and/or installation processes failing due to the inability to start daemons. A badly written script may even kill a daemon on the host system before starting up a version in the chroot leading to much confusion (I'm sure I had at least one case many years ago where emails sent to 127.0.0.1:25 seemed to be going nowhere and I finally found out they were being handled by a MTA in a chroot that was configured for "local mail only").

Some distros do have mechanisms to stop package installs in a chroot starting daemons, but the details will obviously be distro-specific.

plugwash
  • 4,352
1

chroot is not a container, and does not completely isolate a process from the rest of the system. If you mount /proc in your chroot directory, a process started in that chroot can see the processes running outside your chroot.

That said, if you don't mind that, chroot is designed to handle exactly the cases you're describing. In fact, before multiarch support in Debian, the recommended way to run 32-bit apps on a 64-bit system was to make a 32-bit chroot and install a minimal 32-bit Debian base.

Dylan Frese
  • 572
  • Thanks. Really reassuring to know Debian even recommended it at some point of time for 32-bit support on 64-bit machines. At-least if some one says its too much hack, I have a real example to point out. – Nishant Aug 30 '16 at 19:03
  • Also if you have access to /proc (maybe /sys), then you can escape. Look at /proc/self/root (you would have to replace self with a pid of a process that is not in the chroot). – ctrl-alt-delor Jun 18 '18 at 18:51