Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible for a non-root user to run a chroot process on Ubuntu?

share|improve this question
This old FreeBSD thread covers the same question:… Short answer: No, you cannot run a process as root within a non-root chroot jail. – David Harrison Apr 25 '10 at 9:19
chroot jails are specific to bsd. a chroot in linux is not a jail. Last I checked it was not possible to chroot as a user. – xenoterracide Apr 25 '10 at 10:11
@xenoterracide Jails are BSD specific, but chroot is commonly known as a "chroot jail" in the Linux community. It's quite confused. – pehrs Apr 25 '10 at 19:46
What are you trying to do and why? There are tools like fakechroot, and schroot that make provide a workable alternative depending on your requirements. – Zoredache Apr 25 '10 at 22:32
There was also more related discussion at How to “jail” a process without being root? with more working or tentative approaches to solving this task listed. – imz -- Ivan Zakharyaschev May 21 '11 at 5:15
up vote 8 down vote accepted

On Linux the chroot(2) system call can only be made by a process that is privileged. The capability the process needs is CAP_SYS_CHROOT.

The reason you can't chroot as a user is pretty simple. Assume you have a setuid program such as sudo that checks /etc/sudoers if you are allowed to do something. Now put it in a chroot chroot with your own /etc/sudoers. Suddenly you have an instant privilege escalation.

It is possible to design a program to chroot itself and run it as a setuid process, but this is generally considered bad design. The extra security of the chroot does not motivate the security issues with the setuid.

share|improve this answer
With the new possibilities of namespaces in linux, perhaps it's possible to create (unshare) a new "user" namespace, where there would be an "embedded" root user, and perform chroot then. – imz -- Ivan Zakharyaschev Jan 10 '13 at 16:46
@imz--IvanZakharyaschev You're absolutely correct, and I hope you don't mind me having taken the liberty of writing that up as an easily testable answer. – hvd Dec 2 '14 at 19:28
@hvd Great! It must be a very useful, because it demonstrates how to use the new unfamiliar Linux features with concrete commands. – imz -- Ivan Zakharyaschev Dec 3 '14 at 9:36

@imz--IvanZakharyaschev comments on pehrs's answer that it may be possible with the introduction of namespaces, but this hasn't been tested and posted as an answer. Yes, that does indeed make it possible for a non-root user to use chroot.

Given a statically-linked dash, and a statically-linked busybox, and a running bash shell running as non-root:

$ mkdir root
$ cp /path/to/dash root
$ cp /path/to/busybox root
$ unshare -r bash -c 'chroot root /dash -c "/busybox ls -al /"'
total 2700
drwxr-xr-x    2 0        0             4096 Dec  2 19:16 .
drwxr-xr-x    2 0        0             4096 Dec  2 19:16 ..
drwxr-xr-x    1 0        0          1905240 Dec  2 19:15 busybox
drwxr-xr-x    1 0        0           847704 Dec  2 19:15 dash

The root user ID in that namespace is mapped to the non-root user ID outside of that namespace, and vice versa, which is why the system shows files owned by the current user as owned by user ID 0. A regular ls -al root, without unshare, does show them as owned by the current user.

Note: it's well-known that processes that are capable of using chroot, are capable of breaking out of a chroot. Since unshare -r would grant chroot permissions to an ordinary user, it would be a security risk if that was allowed inside a chroot environment. Indeed, it is not allowed, and fails with:

unshare: unshare failed: Operation not permitted

which matches the unshare(2) documentation (apologies for the weird bolding, but that's what it looks like):

EPERM (since Linux 3.9)

CLONE_NEWUSER was specified in flags and the caller is in a chroot environment (i.e., the caller's root directory does not match the root directory of the mount namespace in which it resides).

share|improve this answer

These days, you want to be looking at LXC (Linux Containers) instead of chroot/BSD jail. It's somewhere between a chroot and a virtual machine, giving you a lot of security control and general configurability. I believe all you need to run it as a user is to be a member of the group that owns the necessary files/devices, but there might also be capabilities/system permissions involved. Either way, it should be very doable, since LXC is quite recent, long after SELinux etc. was added to the Linux kernel.

Also, bear in mind that you can just write scripts as root but give users secure permission to run those scripts (without a password if you like, but make sure the script is secure) using sudo.

share|improve this answer

No. If I recall correctly there is some kernel level thing that chroot does that prevents it. I don't recall what that thing was. I investigated it back when messing with Gentoo's Catalyst Build tool (and a chroot on gentoo is the same as a chroot on ubuntu). Though it would be possible to make it happen without a passwd... but such things are left to the realm of potential security vulnerabilities and making sure you know what you are doing.

share|improve this answer

The combination of fakeroot / fakechroot gives a simulacre of chroot for simple needs such as producing tar archives where files appear to be owned by root. Fakechroot manpage is

You don't get any new permission though, but if you own a directory (e.g. fake-distro) before invoking

fakechroot fakeroot chroot ~/fake-distro some-command

it now look for some-command like you're root and owning everything within fake-distro.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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