The `sudo chroot /chroot su - user -c "cmd args"` trick

Ok, this is going to be an article for beginners but with a spin at the end even for the most advanced users. Let's say you want to run a command inside of chroot as another user all in a single command and be back at your shell. How do you do it? Turns out it can be easily done by combining several commands in a beautiful way:

sudo chroot /chroot su - user -c "cmd args"

It may seem a pretty crazy combination of commands but it's all really easy to undestand. First, let's take a look at man chroot. It says,

sudo chroot /chroot command

Okay, so we can run command inside of chroot as root, but how do we run the command inside of chroot as another user? How about using su for command? Let's try that:

sudo chroot /chroot su - user

This runs su inside of chroot as user but we get an interactive shell. Let's take a closer look at man su. It says that we could try:

sudo su - user -c "cmd args"

This runs the cmd args through the shell. Great! So let's use this together with chroot again:

sudo chroot /chroot su - user -c "cmd args"

Excellent! Almost what we needed. However there is still one small problem. If the user has a custom environment (such as different PATHs to executables or some other customizations), it won't get initialized, so we've to source the initialization file(s) ourselves:

sudo chroot /chroot su - user -c ". ~/.bash_profile; cmd args"

This does what we wanted and runs cmd args inside of chroot located at /new-root-path as user and after running the command it quits and we're back at our shell.

What a beautiful way to combine commands!

On Sourcing ~/.bash_profile

Some people couldn't understand why I was sourcing ~/.bash_profile. The reason is because I was unable to find another way to invoke the login shell and have the environment initialized.

I tried this:

sudo chroot /chroot su -l user -c "cmd args"

And it just wouldn't execute ~/.bash_profile. Su's man page says that -l invokes a login shell, however I don't see that happening. Here's the transcript that demonstrates it:

pkrumins$ pwd
/chroot

pkrumins$ sudo cat ./home/testuser1/.bash_profile 
echo "moo"
PATH="/test/bin"

pkrumins$ sudo chroot /chroot su -l testuser1 -c 'echo $PATH'
/bin:/usr/bin

pkrumins$ sudo chroot /chroot su -l testuser1 
moo

testuser1$ echo $PATH
/test/bin

testuser1$ ^D
logout

pkrumins$ sudo chroot /chroot su -l testuser1 -c '. ~/.bash_profile; echo $PATH'       
moo
/test/bin

pkrumins$ sudo chroot /chroot su -l testuser1
moo

testuser1$ /bin/bash -l -c 'echo $PATH'
moo
/test/bin

This definitely looks like a bug in su to me when -l and -c are used together. So the only way to get the environment loaded is by sourcing the initialization files yourself.

Update

I went through su's source code (can be found in util-linux package) and it turns out it's not a bug in su!

Here are the arguments that su passes to execv when I run su user -c 'echo $PATH' (see run_shell function in su.c):

shell: /bin/bash
args[0]: -bash
args[1]: -c
args[2]: echo $PATH

As you can see, args[0][0] is -, which makes bash a login shell, so bash should be executing the startup files, but it does not!

To figure out what was happening, I built a custom version of bash and added a bunch of debugging statements. I found that there are two different login-shell states! Who'd have thought? One that you get when you've set args[0][0] to -, the other that you get when you've used the -l argument (to bash, not su!).

In case args[0][0] is -, and you're using -c to execute code, bash will not execute startup files because it's in this "non-interactive positive-login-shell" state. However if you use -l and -c, it goes into "non-interactive negative-login-shell" state, and it will execute startup files (see run_startup_files function in bash's shell.c source file).

That was one hell of an adventure debugging this. So if you want bash to execute startup files through su, use my ". ~/.bash_profile" sourcing trick! (Or define NON_INTERACTIVE_LOGIN_SHELLS when building bash).