[lkml]   [2011]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: chroot(2) and bind mounts as non-root
I'm genuinely confused whether all these concerns are valid with file

Consider (let's say luser is some user that I want to be active inside
the chroot, but I don't want to allow regular login to my system):

morgan> sudo su luser
luser> mkdir /tmp/chroot/
luser> chmod go-rx /tmp/chroot/
luser> exit

morgan> cat > launcher.c <<EOT
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv)
int ret = chroot("/tmp/chroot");
printf("chroot %s.\n", ret ? "failed" : "worked");
ret = chdir("/");
printf("chdir %s.\n", ret ? "failed" : "worked");
// Insert exec code to invoke chroot'd shell or whatever.
return ret;
morgan> make launcher
cc launcher.c -o launcher
morgan> mv launcher /tmp/
morgan> sudo -s
root> setcap cap_sys_chroot=ep /tmp/launcher
root> cp <files and directories needed in the chroot> /tmp/chroot/
root> su luser

luser> /tmp/launcher

The last line being something that involves luser only - ie. it gives
no user privilege away to any child it might launch. Its also the only
regular user able to chroot to this luser owned chroot (because that
directory is exclusive to that user).

Is there a need for privileged binaries within /tmp/chroot? If not,
how might they get there (without help from root, always presuming I
can prevent luser from logging in outside of this chroot'd



On Wed, Dec 7, 2011 at 12:54 PM, Alan Cox <> wrote:
> On Wed, 07 Dec 2011 12:34:28 -0800
> "H. Peter Anvin" <> wrote:
>> On 12/07/2011 09:54 AM, Colin Walters wrote:
>> >
>> > The historical reason one can't call chroot(2) as non-root is because of
>> > setuid binaries (hard link a setuid binary into chroot of your choice
>> > with trojaned
>> No.  The historical reason is that it lets anyone escape a chroot jail:
> Beg to differ
> Nobody ever considered chroot a jail except a certain brand of
> urban-legend-programming people. Indeed chroot has never been a jail
> except in the 'open prison' security sense of it.
> The big problem with chroot was abusing setuid binaries - particularly
> things like uucp and /bin/mail.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-12-15 19:57    [W:0.089 / U:0.280 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site