diff options
author | 2017-04-12 17:22:14 -0500 | |
---|---|---|
committer | 2017-04-21 16:08:19 -0500 | |
commit | cad4ea546b1a8a700d269e41ac5db182057d7a32 (patch) | |
tree | b11a5259d2b25b2f30c942bce0dd9900a1c7cff1 | |
parent | signal: Remove unused definition of sig_user_definied (diff) | |
download | linux-cad4ea546b1a8a700d269e41ac5db182057d7a32.tar.gz linux-cad4ea546b1a8a700d269e41ac5db182057d7a32.tar.bz2 linux-cad4ea546b1a8a700d269e41ac5db182057d7a32.zip |
rlimit: Properly call security_task_setrlimit
Modify do_prlimit to call security_task_setrlimit passing the task
whose rlimit we are changing not the tsk->group_leader.
In general this should not matter as the lsms implementing
security_task_setrlimit apparmor and selinux both examine the
task->cred to see what should be allowed on the destination task.
That task->cred is shared between tasks created with CLONE_THREAD
unless thread keyrings are in play, in which case both apparmor and
selinux create duplicate security contexts.
So the only time when it will matter which thread is passed to
security_task_setrlimit is if one of the threads of a process performs
an operation that changes only it's credentials. At which point if a
thread has done that we don't want to hide that information from the
lsms.
So fix the call of security_task_setrlimit. With the removal
of tsk->group_leader this makes the code slightly faster,
more comprehensible and maintainable.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
-rw-r--r-- | kernel/sys.c | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/kernel/sys.c b/kernel/sys.c index 7ff6d1b10cec..ad1eff7933cb 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -1396,8 +1396,7 @@ int do_prlimit(struct task_struct *tsk, unsigned int resource, !capable(CAP_SYS_RESOURCE)) retval = -EPERM; if (!retval) - retval = security_task_setrlimit(tsk->group_leader, - resource, new_rlim); + retval = security_task_setrlimit(tsk, resource, new_rlim); if (resource == RLIMIT_CPU && new_rlim->rlim_cur == 0) { /* * The caller is asking for an immediate RLIMIT_CPU |