summaryrefslogtreecommitdiffstats
path: root/lib/syscall.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2013-03-15 01:45:51 -0700
committerEric W. Biederman <ebiederm@xmission.com>2013-03-27 07:49:29 -0700
commit3151527ee007b73a0ebd296010f1c0454a919c7d (patch)
tree33175354889523cd20586fb28456e566529c46d9 /lib/syscall.c
parenteddc0a3abff273842a94784d2d022bbc36dc9015 (diff)
downloadop-kernel-dev-3151527ee007b73a0ebd296010f1c0454a919c7d.zip
op-kernel-dev-3151527ee007b73a0ebd296010f1c0454a919c7d.tar.gz
userns: Don't allow creation if the user is chrooted
Guarantee that the policy of which files may be access that is established by setting the root directory will not be violated by user namespaces by verifying that the root directory points to the root of the mount namespace at the time of user namespace creation. Changing the root is a privileged operation, and as a matter of policy it serves to limit unprivileged processes to files below the current root directory. For reasons of simplicity and comprehensibility the privilege to change the root directory is gated solely on the CAP_SYS_CHROOT capability in the user namespace. Therefore when creating a user namespace we must ensure that the policy of which files may be access can not be violated by changing the root directory. Anyone who runs a processes in a chroot and would like to use user namespace can setup the same view of filesystems with a mount namespace instead. With this result that this is not a practical limitation for using user namespaces. Cc: stable@vger.kernel.org Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Reported-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Diffstat (limited to 'lib/syscall.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud