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.

Improve this question
4
  • 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. Commented Aug 30, 2016 at 17:47
  • I just use the normal chroot even on Arch. For 32-bit containers I do linux32 chroot <path-to-root> Commented Aug 30, 2016 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) Commented Aug 30, 2016 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. Commented Aug 30, 2016 at 19:25

2 Answers 2

Reset to default
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.

Improve this answer
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.

Improve this answer
2
  • 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. Commented Aug 30, 2016 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). Commented Jun 18, 2018 at 18:51

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.