[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.022 / U:15.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site