Re: getrlimit failed (chromium on musl)

[He X <xw897002528@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]

After patched,  chromium segfault three times in two days, e.g. when i try
to upload a file in a baiduyun, crash when i click the upload button, and
suddenly crashed twice, when --disable-sandbox, no crashing:
[65422.256448] chromium[12257]: segfault at 3c1 ip 00007f69e30e075c sp
00007ffe5442efc0 error 4 in libc.so[7f69e30b9000+a1000]

strace output(should be this one):
13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024,
rlim_max=4*1024}, NULL) = 0
13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1
13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295, NULL)
= 0
13:52:37.479961 rt_sigreturn({mask=[]}) = 61
13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
13:53:23.970709 wait4(29341,  <unfinished ...>) = ?
13:53:30.693847 +++ killed by SIGSEGV +++

This patch is a bit dangerous, though it indeed solved the problem, i think
EPERM is needed. Modifying musl is a better way, but is that correct?


2017-01-27 8:41 GMT+08:00 Alba Pompeo <albapompeo@gmail.com>:

> The patch worked.
> Many thanks Samuel.
> I hope they fix it upstream too for the future.
> Sadly Chromium still needs some patches to compile and work on musl.
>
>
>
> On Wed, Jan 18, 2017 at 2:13 PM, Alba Pompeo <albapompeo@gmail.com> wrote:
> > Ran strace -f.
> >
> > [pid 13354] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024,
> > rlim_max=4*1024}) = 0
> > [pid 13350] clone(child_stack=NULL, flags=CLONE_NEWUSER|SIGCHLD) = -1
> > EPERM (Operation not permitted)
> > [pid 13354] clone(child_stack=NULL,
> > flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not
> > permitted)
> > [pid 13354] writev(2, [{iov_base=" but failed: errno = Operation
> > n"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2 but failed: errno =
> > Operation not permitted
> >
> > So the patch from Samuel should be a real solution.
> >
> > Thanks.
> >
> >
> >
> > On Wed, Jan 18, 2017 at 1:51 PM, Samuel Holland <samuel@sholland.org>
> wrote:
> >> On 01/18/17 08:08, Alba Pompeo wrote:
> >>>
> >>> Hi.
> >>>
> >>> Running chromium on a musl system spams this message.
> >>>
> >>> getrlimit(RLIMIT_NOFILE) failed
> >>>
> >>> Any idea how to figure out what's wrong?
> >>
> >>
> >> 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.
> >>
> >> ---
> >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_
> renderer_policy_linux.cc.orig
> >> +++
> >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_
> renderer_policy_linux.cc
> >> @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int
> >> sysno) const {
> >>      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);
> >>
> >>> Thanks.
> >>
> >>
> >> Regards,
> >> Samuel
> >>
>

[-- Attachment #2: Type: text/html, Size: 4780 bytes --]