summaryrefslogtreecommitdiffstats
path: root/kernel/pid.c
diff options
context:
space:
mode:
authorEric Paris <eparis@redhat.com>2013-07-03 15:08:29 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2013-07-03 16:08:03 -0700
commitb57922b6c76c3ee401bb32fd3f298409dd6e6a53 (patch)
treef9c8509215a9e5333accfa80f4e97bb0cd068209 /kernel/pid.c
parent30bc30df102b2d0c003d93477e04b97e6c528573 (diff)
downloadlinux-b57922b6c76c3ee401bb32fd3f298409dd6e6a53.tar.bz2
fork: reorder permissions when violating number of processes limits
When a task is attempting to violate the RLIMIT_NPROC limit we have a check to see if the task is sufficiently priviledged. The check first looks at CAP_SYS_ADMIN, then CAP_SYS_RESOURCE, then if the task is uid=0. A result is that tasks which are allowed by the uid=0 check are first checked against the security subsystem. This results in the security subsystem auditting a denial for sys_admin and sys_resource and then the task passing the uid=0 check. This patch rearranges the code to first check uid=0, since if we pass that we shouldn't hit the security system at all. We then check sys_resource, since it is the smallest capability which will solve the problem. Lastly we check the fallback everything cap_sysadmin. We don't want to give this capability many places since it is so powerful. This will eliminate many of the false positive/needless denial messages we get when a root task tries to violate the nproc limit. (note that kthreads count against root, so on a sufficiently large machine we can actually get past the default limits before any userspace tasks are launched.) Signed-off-by: Eric Paris <eparis@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel/pid.c')
0 files changed, 0 insertions, 0 deletions