Is Chroot Still Useful In 2023?

Not_OlesNot_Oles Hosting ProviderContent Writer

Does anybody here use chroot nowadays?

With KVM and LXC and other virtualization technologies being very popular now, chroot might not seem needed very often any more. Nevertheless, I had a lot of fun last night making a chroot environment.

With debootstrap, the chroot was super fast and easy to set up. It seems to work okay, has network access, I can ssh in, etc.

Wikipedia's chroot article tells the very interesting history of chroot, beginning with its introduction in v7 Unix in 1979. The linked Wikipedia article also contains an interesting section on the limitations of chroot. However, the limitations might not be especially significant for every use case.

Is it too crazy to imagine that chroot still might be very useful today? For example, if all one needs is a quick test of something? As another example, Hetzner uses chroot in Installimage, which is one of Hetzner's methods to install Operating Systems on dedicated servers.

Here, from Installimage, are lines 9 through 27 of chroot.functions.sh, where execute_chroot_command() is defined:

execute_chroot_command_wo_debug() {
  local dirs=(/{dev,dev/pts,dev/shm,proc,run,sys})
  for dir in "${dirs[@]}"; do
    mkdir -p "$FOLD/hdd/$dir"
    mount --bind "$dir" "$FOLD/hdd/$dir"
  done
  unshare -f -p chroot "$FOLD/hdd" /usr/bin/env bash -c "$@"
  local r=$?
  for ((i=${#dirs[@]}-1; i>=0; i--)); do
    until umount "$FOLD/hdd/${dirs[i]}"; do :; done
  done
  return $r
}

execute_chroot_command() {
  debug "# chroot: $*"
  execute_chroot_command_wo_debug "$@" |& debugoutput
  return "${PIPESTATUS[0]}"
}

Please see also Installimage's functions.sh where execute_chroot_command() appears 14 times.

I hope to learn more about the unshare system call, which Installimage uses in the function execute_chroot_command_wo_debug(), and which "allows a process (or thread) to disassociate parts of its execution context that are currently being shared with other processes (or threads)."

People here at LES are invited to teach and learn together with me on MetalVPS. If you think you might like a MetalVPS account, please check the current offer at Free Debian Sid Intel i9-12900K Shell Accounts from MetalVPS!

I wonder how many people here still use chroot? And, besides Installimage, what are other current uses of chroot these days?

Friendly greetings! :)

Thanked by (2)chris Mason
Tagged:

Comments

  • Yeah I use it, apart from testing, there are use cases that the level of chroot isolation is exactly right.

    Thanked by (1)Not_Oles
  • Not_OlesNot_Oles Hosting ProviderContent Writer

    @itsdeadjim said:
    Yeah I use it, apart from testing, there are use cases that the level of chroot isolation is exactly right.

    Hi! Can you please share a little detail about what you use chroot for and why the level of isolation is exactly right? Thanks!

  • chroot is perfect for handling obsolete software that depends on old system libraries. In such cases, only filesystem isolation is needed, and that's due to compatibility not security, so anything above chroot is overkill and complicates setup for no benefit.

    lxc is just a more complicated chroot, so the real question is not whether chroot is still useful, but why use anything else when you dont need to.

    Thanked by (1)Not_Oles
  • Not_OlesNot_Oles Hosting ProviderContent Writer

    Yeah, I could see using chroot for running some program dependent on some old system library either not present or present, but in an incompatible although newer version, on the main system. Thanks for the helpful addition to your previous comment! :)

  • Always insightful, nice to ponder something normal now and again!

    Thanked by (1)Not_Oles
  • @itsdeadjim @Not_Oles shameless plug here. Use Nix or NixOS, library compatibilities be damned! XD

    Thanked by (2)itsdeadjim Not_Oles

    The all seeing eye sees everything...

  • @Not_Oles said: I wonder how many people here still use chroot?

    I used to use chroot until recently to get a Tizen build environment on my Orange Pi PC (or an Oracle A1 instance) running Ubuntu, but I have now switched to bubblewrap as it essentially combines chroot with unshare.

    BTW, I also tend to isolate server applications using bubblewrap nowadays (although I don't have a separate chroot for these, I just bind-mount specific parts of the host filesystem so the application only has access to what it needs).

    Thanked by (1)Not_Oles
  • Not_OlesNot_Oles Hosting ProviderContent Writer

    @cmeerw said:

    @Not_Oles said: I wonder how many people here still use chroot?

    I used to use chroot until recently to get a Tizen build environment on my Orange Pi PC (or an Oracle A1 instance) running Ubuntu, but I have now switched to bubblewrap as it essentially combines chroot with unshare.

    BTW, I also tend to isolate server applications using bubblewrap nowadays (although I don't have a separate chroot for these, I just bind-mount specific parts of the host filesystem so the application only has access to what it needs).

    My notes remind me that you already mentioned bubblewrap before, in your comment showing your bubblewrap wrapper designed to facilitate IPv4 domain resolution via nat64.xyz without changing /etc/resolv.conf.

    Thanks for mentioning bubblewrap again. I had looked very quickly at the bubblewrap Github repo, but I didn't catch the use of unshare even though it appears in the trimmed down demo script in the README.md. I will look some more. :)

    May I please ask what is|are the major reason(s) why you want to "isolate server applications . . . nowadays?" I can imagine, for example, protection from bugs or even deliberate hacks in untrusted server application code. Is that the reason, or is there something else which is important and that I am missing? Thanks! :)

  • @Not_Oles said: May I please ask what is|are the major reason(s) why you want to "isolate server applications . . . nowadays?" I can imagine, for example, protection from bugs or even deliberate hacks in untrusted server application code. Is that the reason, or is there something else which is important and that I am missing? Thanks!

    That's exactly it, just an additional layer of protection that doesn't cost anything.

    Thanked by (1)Not_Oles
  • I only use chroot for rescue mode up until now. maybe it's because i mostly use an environment on my own, it's free real estate

    Thanked by (1)Not_Oles

    Fuck this 24/7 internet spew of trivia and celebrity bullshit.

  • @Not_Oles said: With KVM and LXC and other virtualization technologies being very popular now, chroot might not seem needed very often any more.

    chroot() might not seem needed very often, however Docker, LXC and the like all use chroot() for their filesystem isolation. In the case of Docker for example, it constructs a union of various layers specified in the Docker image, and then chroot()s into that environment, apart from using other Linux container technology such as namespaces and cgroups.

    For a better overview of these topics, have a look at this video:

    Thanked by (1)Not_Oles
  • Not_OlesNot_Oles Hosting ProviderContent Writer
    edited February 2023

    Hi @supriyo_biswas!

    Thanks for suggesting Liz Rice's wonderful video! I had mentioned this video back in December 2022:

    Could your use case work with any of the following (with needed updates / modifications) or with something else that's more simple than full LXC, KVM, or Docker?

    Thanks very much! Best wishes!

    Here are some places in the LXC source code where chroot is mentioned/used:

    fmt:~/lxc/src/lxc$ grep -nr chroot 
    lxccontainer.c:4560:    char chrootpath[PATH_MAX];
    lxccontainer.c:4580:    ret = strnprintf(chrootpath, sizeof(chrootpath), "/proc/%d/root", init_pid);
    lxccontainer.c:4584:    ret = chroot(chrootpath);
    open_utils.h:55:                                        (similar to chroot(2)). */
    conf.c:210:     { "sys_chroot",         CAP_SYS_CHROOT         },
    conf.c:1465:static int lxc_chroot(const struct lxc_rootfs *rootfs)
    conf.c:1548:    ret = chroot(".");
    conf.c:1550:            return log_error_errno(-1, errno, "Failed to chroot(\".\")");
    conf.c:1662:            return lxc_chroot(rootfs);
    utils.c:704: * IIUC, so long as we've chrooted so that rootfs is not our root,
    fmt:~/lxc/src/lxc$ 
    

    I don't have the Docker source code handy, so I can't as easily check for chroot in Docker until another time soon.

    It would be super great if somebody came aboard MetalVPS' free i9-9900K server who was interested in updating Liz Rice's 500 lines of C code or her Go code! Or similar!

    Best wishes and thanks again, @supriyo_biswas!

  • edited March 2023

    it's unuseful for me, because chroot is only available on rooted android phone within termux. therefore i use proot instead. :'(

    Thanked by (2)Not_Oles ehab
  • Not_OlesNot_Oles Hosting ProviderContent Writer
    edited March 2023

    @mfvps Wow! proot seems ingenious! Thanks for your comment, which helped me a lot because I didn't know about proot! 🤩

    The llinked page says:

    PRoot is a user-space implementation of chroot, mount --bind, and binfmt_misc. This means that users don't need any privileges or setup to do things like using an arbitrary directory as the new root filesystem, . . .
    The new root file-system, a.k.a guest rootfs, typically contains a Linux distribution.

    If somebody here at LES was offering unprivileged shell accounts, a situation somewhat analogous to termux on unrooted Android, . . .

  • ehabehab Content Writer

    @mfvps said:

    Thank you so much for proot i tried it and it works :) fine compiling some packages.

    Thanked by (1)Not_Oles
Sign In or Register to comment.