In every tutorial I found online about chrooting, there is part involving copying stuff into the chroot, executables, libraries and others. Why is that? Why not just mount --bind the stuff in? Wouldn't that have an advantage of automatic updatec with rest of the system?

  • The tutorial might have been written for not-Linux, or Linux-pre-2.4.0, or the author may not have known about that mount option. Also, security implications if the mount is readwrite.
    – thrig
    Aug 28, 2015 at 21:29
  • most of the stuff you want to mount is root owned anyway and since program in chroot is not running as root most of the time, I honestly don't see security implications (when using same common sense)
    – graywolf
    Aug 28, 2015 at 21:34
  • web.nvd.nist.gov/view/vuln/… shows a number of chroot related vulnerabilities, beyond an obvious escalate-to-root-via-some-other-bug-and-then-write-outside-the-chroot-if-mount-readwrite. Even if read-only, there may remain some clever means to abuse a bind mount a forthcoming CVE might have to address. Hence, security implications.
    – thrig
    Aug 28, 2015 at 22:02

1 Answer 1


Depends on why you want a chroot.

If you need it because you need a minimal sandbox for something you don't trust, then copying files allows you to limit what's in the chroot; a bindmount works on whole directories.

If you need an older (or newer) distribution than your host system, then a bindmount won't help you.

Sometimes you want a chroot that is almost exactly the same as the host system, in which case a bindmount might make sense, but in my experience that's almost never the case.

  • Not true, you can mount --bind individual files as well. I mostly want it for increasing security by locking each service into minimal sandbox
    – graywolf
    Aug 28, 2015 at 23:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .