Chroot allows us to change the root directory, or rather root directory of specific process. Now obviously this does restrict the process to the specified tree (unless it doesn't relinquish the privilidges).

But I wondered what other limitations could arise within this context. Specifically regarding access to devices, and other resources. Provided that the process doesn't chroot out, back into original tree, obviously.

It seems to me that such massive change should have further implications for system functionality. But I couldn't find anything specific.

Maybe there are none, but that doesn't seem likely, and I would still rather prefer to know for sure.

closed as too broad by Ipor Sircer, roaima, shirish, agc, Kusalananda May 15 '18 at 10:17

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


Functionally, nothing. Literally all that the chroot() call does is update where the kernel anchors path resolution for your process. In particular, unless you also drop root privileges, you can still access /proc and /sys (because you can just make the appropriate mount() system calls, no external binary needed), you can still access device nodes (you can just create them with the mknod() system call, again no external binary needed), and really do just about everything else you can imagine.

If you drop root privileges right after entering the chroot (like most well behaved applications do), you can still do anything you could do from the user context you switch to, provided you don't need any external programs or libraries. that aren't in the chroot environment.

Note however that even then, a chroot is of almost zero practical security value by itself. It's actually really easy to escape a chroot through a wide variety of mechanisms (seriously, just search 'escape from chroot' on your favorite search engine, and you'll find results listing at least half a dozen methods). All that's needed to exploit this in any arbitrary application is an ACE vulnerability. In fact, chroot() was not originally intended for security at all, it was (and still is) a developers tool intended to allow testing new software in an isolated environment (among other things, these days it's more often used to provide an isolated build environment in automated build and CI systems).

  • you can do almost anything you could do from that user context. you can't enter a new user namespace :-), because amusingly that would let you escape chroot. unix.stackexchange.com/questions/442996/… – sourcejedi May 14 '18 at 22:11
  • I knew about chroot being very insecure. As you said that wasn't a design consideration. My question was only about the limits it imposes by default. And you answered that very well. – user1561358 May 15 '18 at 8:42
  • @sourcejedi I actually didn't know that entering a new user namespace was not possible from within a chroot on Linux (I did know you can trivially escape them by doing so, I just didn't know it was blocked). – Austin Hemmelgarn May 15 '18 at 19:17

Access to devices: unless the chroot environment includes its own copy of the necessary device nodes, there will be no access. For example, you may find that e.g. chrooted interactive shells can behave oddly if there is no /dev/null device node within the chroot environment.

A process within a chroot environment will also be unable to send out syslog messages, unless you configure your syslog daemon to create an additional /dev/log within the chroot environment.

If the /proc and /sys filesystems have not been bind-mounted or otherwise provided within the chroot environment, any system status query tools that use them will not work.

Not the answer you're looking for? Browse other questions tagged or ask your own question.