aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/event_analyzing_sample.py
diff options
context:
space:
mode:
authorEric W. Biederman <[email protected]>2022-02-24 08:32:28 -0600
committerEric W. Biederman <[email protected]>2022-02-25 10:40:14 -0600
commit0ac983f512033cb7b5e210c9589768ad25b1e36b (patch)
tree23346def96dea0b7f0a82c7eb21f9ab22bc36264 /tools/perf/scripts/python/event_analyzing_sample.py
parent0cbae9e24fa7d6c6e9f828562f084da82217a0c5 (diff)
ucounts: Fix systemd LimitNPROC with private users regression
Long story short recursively enforcing RLIMIT_NPROC when it is not enforced on the process that creates a new user namespace, causes currently working code to fail. There is no reason to enforce RLIMIT_NPROC recursively when we don't enforce it normally so update the code to detect this case. I would like to simply use capable(CAP_SYS_RESOURCE) to detect when RLIMIT_NPROC is not enforced upon the caller. Unfortunately because RLIMIT_NPROC is charged and checked for enforcement based upon the real uid, using capable() which is euid based is inconsistent with reality. Come as close as possible to testing for capable(CAP_SYS_RESOURCE) by testing for when the real uid would match the conditions when CAP_SYS_RESOURCE would be present if the real uid was the effective uid. Reported-by: Etienne Dechamps <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215596 Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") Reviewed-by: Kees Cook <[email protected]> Signed-off-by: "Eric W. Biederman" <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/event_analyzing_sample.py')
0 files changed, 0 insertions, 0 deletions