On Sat, Jan 2, 2016 at 8:52 AM, Jann Horn <jann@xxxxxxxxx> wrote:
> Allow unprivileged processes to chroot() themselves, under the
> following conditions:
>
> - The caller must have set NO_NEW_PRIVS to prevent him from
> invoking setuid/setgid/setcap executables in the chroot that
> could be tricked into opening files from the chroot.
> - The fs_struct must not be shared to prevent the caller from
> chrooting another process that does not have NO_NEW_PRIVS
> active.
> - chroot() is sometimes (mis-)used for sandboxing purposes.
> To prevent a simple chroot breakout using e.g. the
> double-chroot trick (chdir("/"), chroot("/foo"),
> chroot("../../../../../../../../")), require the process to
> be un-chrooted before performing chroot()
What is the use case?
If you want to jail yourself as non-root you can create a new user and
mount namespace.
Then you're allowed to change root.
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
