From a24ac7cc23b2507ee42b078e1d68be28be78e181 Mon Sep 17 00:00:00 2001 From: Jakub Jirutka Date: Thu, 19 Jan 2017 23:31:01 +0100 Subject: community/chromium: fix getrlimit(RLIMIT_NOFILE) failed --- community/chromium/musl-fix-getrlimit-failed.patch | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 community/chromium/musl-fix-getrlimit-failed.patch (limited to 'community/chromium/musl-fix-getrlimit-failed.patch') diff --git a/community/chromium/musl-fix-getrlimit-failed.patch b/community/chromium/musl-fix-getrlimit-failed.patch new file mode 100644 index 0000000000..08692abf16 --- /dev/null +++ b/community/chromium/musl-fix-getrlimit-failed.patch @@ -0,0 +1,24 @@ +Date: Wed, 18 Jan 2017 09:51:29 -0600 +From: Samuel Holland +Subject: Re: getrlimit failed (chromium on musl) + +> Running chromium on a musl system spams this message: +> +> getrlimit(RLIMIT_NOFILE) failed + +The problem is that the sandbox blocks prlimit64 with EPERM, but musl +only falls back to getrlimit on ENOSYS. The diff below will fix the +error. From the linked bug, the only reason it is blocked in the first +place is ChromeOS, and this change should be fine even there. + +--- content/common/sandbox_linux/bpf_renderer_policy_linux.cc.orig ++++ content/common/sandbox_linux/bpf_renderer_policy_linux.cc +@@ -88,7 +88,7 @@ + case __NR_sched_setscheduler: + return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno); + case __NR_prlimit64: +- return Error(EPERM); // See crbug.com/160157. ++ return Error(ENOSYS); // See crbug.com/160157. + default: + // Default on the content baseline policy. + return SandboxBPFBasePolicy::EvaluateSyscall(sysno); -- cgit v1.2.3