Tasks are associated to multiple users at once. Historically and as per
setrlimit(2) RLIMIT_NPROC is enforce based on real user ID.
The commit 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
made the accounting structure "indexed" by euid and hence potentially
account tasks differently.
The effective user ID may be different e.g. for setuid programs but
those are exec'd into already existing task (i.e. below limit), so
different accounting is moot.
Some special setresuid(2) users may notice the difference, justifying
this fix.
(This is just illustrative, it piggy-backs onto nproc_flags and should
be implemented properly.)
Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
Signed-off-by: Michal Koutný <[email protected]>
---
kernel/cred.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/cred.c b/kernel/cred.c
index 791cab70b764..ed247daa1f67 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -668,6 +668,7 @@ int set_cred_ucounts(struct cred *new, unsigned int *nproc_flags)
struct task_struct *task = current;
const struct cred *old = task->real_cred;
struct ucounts *new_ucounts, *old_ucounts = new->ucounts;
+ kuid_t new_uid = nproc_flags ? new->uid : new->euid;
if (new->user == old->user && new->user_ns == old->user_ns)
return 0;
@@ -676,10 +677,10 @@ int set_cred_ucounts(struct cred *new, unsigned int *nproc_flags)
* This optimization is needed because alloc_ucounts() uses locks
* for table lookups.
*/
- if (old_ucounts->ns == new->user_ns && uid_eq(old_ucounts->uid, new->euid))
+ if (old_ucounts->ns == new->user_ns && uid_eq(old_ucounts->uid, new_uid))
return 0;
- if (!(new_ucounts = alloc_ucounts(new->user_ns, new->euid)))
+ if (!(new_ucounts = alloc_ucounts(new->user_ns, new_uid)))
return -EAGAIN;
new->ucounts = new_ucounts;
--
2.34.1