Linux Sandbox: Whitelist prlimit64 when used as getrlimit

From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier

Committed: https://crrev.com/5ce3b357d4cb9906b57f5758ef271cb69dbb664b
Cr-Commit-Position: refs/heads/master@{#434872}

[rickyz (no longer on Chrome), 2016-11-11 06:20:23]

lgtm

[Daniel Kurtz, 2016-11-21 09:09:39]

Description was changed from

==========
Linux Sandbox: Whitelist prlimit64 when used on pid 0

From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

The pid argument specifies the ID of the process on which the call is
to operate.  If pid is 0, then the call applies to the calling process.

So, allow prlimit() on pid 0 such that the glib implementation of
getrlimit can succeed.

Luckily RestrictPrlimit64 has already been implemented for use by the Nacl
BPF sandbox.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang
==========

to

==========
Linux Sandbox: Whitelist prlimit64 when used on pid 0

From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

The pid argument specifies the ID of the process on which the call is
to operate.  If pid is 0, then the call applies to the calling process.

So, allow prlimit() on pid 0 such that the glib implementation of
getrlimit can succeed.

Luckily RestrictPrlimit64 has already been implemented for use by the Nacl
BPF sandbox.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang
==========

[Daniel Kurtz, 2016-11-21 09:09:39]

djkurtz@chromium.org changed reviewers:
+ jorgelo@chromium.org, vapier@chromium.org

[Daniel Kurtz, 2016-11-21 09:10:14]

Description was changed from

==========
Linux Sandbox: Whitelist prlimit64 when used on pid 0

From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

The pid argument specifies the ID of the process on which the call is
to operate.  If pid is 0, then the call applies to the calling process.

So, allow prlimit() on pid 0 such that the glib implementation of
getrlimit can succeed.

Luckily RestrictPrlimit64 has already been implemented for use by the Nacl
BPF sandbox.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang
==========

to

==========
From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL such that the glib implementation
of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier
==========

[Daniel Kurtz, 2016-11-21 09:11:31]

On 2016/11/11 06:20:23, rickyz wrote:
> lgtm

Updated per comments by jorgelo & vapier to allow prlimit/prlimit64 when
new_limit==NULL.

[Jorge Lucangeli Obes, 2016-11-21 14:18:43]

https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366: return
If(new_limit == 0, Allow()).Else(Error(EPERM));
Should this also restrict |pid| to the process' PID?

[Daniel Kurtz, 2016-11-21 23:48:34]

On 2016/11/21 14:18:43, Jorge Lucangeli Obes wrote:
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
> (right):
> 
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366:
return
> If(new_limit == 0, Allow()).Else(Error(EPERM));
> Should this also restrict |pid| to the process' PID?

Vapier seemed to think that wasn't necessary to PID restrict "getrlimit".  Do
you think it is still necessary?

[Jorge Lucangeli Obes, 2016-11-22 02:56:04]

On 2016/11/21 23:48:34, Daniel Kurtz wrote:
> On 2016/11/21 14:18:43, Jorge Lucangeli Obes wrote:
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
> > (right):
> > 
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366:
> return
> > If(new_limit == 0, Allow()).Else(Error(EPERM));
> > Should this also restrict |pid| to the process' PID?
> 
> Vapier seemed to think that wasn't necessary to PID restrict "getrlimit".  Do
> you think it is still necessary?

You cannot getrlimit from another process unless you have either
CAP_SYS_RESOURCE or your real UID/GID matches the real/effective/saved UID/GID
of the target process -- which is the case for Chromium. Now, I cannot think of
a situation in which that would be useful, which on the one hand is an argument
to not worry, but it's even more an argument to not allow it. If we don't need
it, let's not allow it.

[Daniel Kurtz, 2016-11-22 04:08:25]

On 2016/11/22 02:56:04, Jorge Lucangeli Obes wrote:
> On 2016/11/21 23:48:34, Daniel Kurtz wrote:
> > On 2016/11/21 14:18:43, Jorge Lucangeli Obes wrote:
> > >
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > > File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > > sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366:
> > return
> > > If(new_limit == 0, Allow()).Else(Error(EPERM));
> > > Should this also restrict |pid| to the process' PID?
> > 
> > Vapier seemed to think that wasn't necessary to PID restrict "getrlimit". 
Do
> > you think it is still necessary?
> 
> You cannot getrlimit from another process unless you have either
> CAP_SYS_RESOURCE or your real UID/GID matches the real/effective/saved UID/GID
> of the target process -- which is the case for Chromium. Now, I cannot think
of
> a situation in which that would be useful, which on the one hand is an
argument
> to not worry, but it's even more an argument to not allow it. If we don't need
> it, let's not allow it.

SGTM!  I'll update the patch.

[Daniel Kurtz, 2016-11-22 09:01:24]

Description was changed from

==========
From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL such that the glib implementation
of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier
==========

to

==========
From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier
==========

[Daniel Kurtz, 2016-11-22 09:07:57]

On 2016/11/22 04:08:25, Daniel Kurtz wrote:
> On 2016/11/22 02:56:04, Jorge Lucangeli Obes wrote:
> > On 2016/11/21 23:48:34, Daniel Kurtz wrote:
> > > On 2016/11/21 14:18:43, Jorge Lucangeli Obes wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > > > File
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
> > > > (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > > >
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366:
> > > return
> > > > If(new_limit == 0, Allow()).Else(Error(EPERM));
> > > > Should this also restrict |pid| to the process' PID?
> > > 
> > > Vapier seemed to think that wasn't necessary to PID restrict "getrlimit". 
> Do
> > > you think it is still necessary?
> > 
> > You cannot getrlimit from another process unless you have either
> > CAP_SYS_RESOURCE or your real UID/GID matches the real/effective/saved
UID/GID
> > of the target process -- which is the case for Chromium. Now, I cannot think
> of
> > a situation in which that would be useful, which on the one hand is an
> argument
> > to not worry, but it's even more an argument to not allow it. If we don't
need
> > it, let's not allow it.
> 
> SGTM!  I'll update the patch.

One part that still bothers me about this patch is that there is another
RestrictPrlimit64() already used by nacl_bpf_sandbox_linux.cc.
However, that API allows sets, and sets a different error condition, so I don't
think we can reusing it here in the renderer will be any simpler.

[Jorge Lucangeli Obes, 2016-11-22 15:59:47]

On 2016/11/22 09:07:57, Daniel Kurtz wrote:
> On 2016/11/22 04:08:25, Daniel Kurtz wrote:
> > On 2016/11/22 02:56:04, Jorge Lucangeli Obes wrote:
> > > On 2016/11/21 23:48:34, Daniel Kurtz wrote:
> > > > On 2016/11/21 14:18:43, Jorge Lucangeli Obes wrote:
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > > > > File
> sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
> > > > > (right):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/2484393004/diff/20001/sandbox/linux/seccomp-b...
> > > > >
> sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366:
> > > > return
> > > > > If(new_limit == 0, Allow()).Else(Error(EPERM));
> > > > > Should this also restrict |pid| to the process' PID?
> > > > 
> > > > Vapier seemed to think that wasn't necessary to PID restrict
"getrlimit". 
> > Do
> > > > you think it is still necessary?
> > > 
> > > You cannot getrlimit from another process unless you have either
> > > CAP_SYS_RESOURCE or your real UID/GID matches the real/effective/saved
> UID/GID
> > > of the target process -- which is the case for Chromium. Now, I cannot
think
> > of
> > > a situation in which that would be useful, which on the one hand is an
> > argument
> > > to not worry, but it's even more an argument to not allow it. If we don't
> need
> > > it, let's not allow it.
> > 
> > SGTM!  I'll update the patch.
> 
> One part that still bothers me about this patch is that there is another
> RestrictPrlimit64() already used by nacl_bpf_sandbox_linux.cc.
> However, that API allows sets, and sets a different error condition, so I
don't
> think we can reusing it here in the renderer will be any simpler.

I don't think so either. The NaCl sandbox does end up beingq quite different
from the regular renderer sandbox.

[Jorge Lucangeli Obes, 2016-11-22 16:06:39]

https://codereview.chromium.org/2484393004/diff/40001/sandbox/linux/seccomp-b...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/2484393004/diff/40001/sandbox/linux/seccomp-b...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366: const
Arg<uintptr_t> new_limit(0);
They cannot both be argument index 0, can they?

int prlimit(pid_t pid, int resource, const struct rlimit *new_limit, struct
rlimit *old_limit);

const Arg<pid_t> pid(0);
const Arg<intptr_t> new_limit(2);

https://codesearch.chromium.org/chromium/src/sandbox/linux/bpf_dsl/bpf_dsl.h?...
for reference.

https://codereview.chromium.org/2484393004/diff/40001/sandbox/linux/seccomp-b...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.h
(right):

https://codereview.chromium.org/2484393004/diff/40001/sandbox/linux/seccomp-b...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.h:101: //
Restrict the new_limit argument to prlimit64() to NULL, and the pid argument
"only allow only" -> "only allow"

[Daniel Kurtz, 2016-11-23 00:21:14]

https://codereview.chromium.org/2484393004/diff/40001/sandbox/linux/seccomp-b...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/2484393004/diff/40001/sandbox/linux/seccomp-b...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:366: const
Arg<uintptr_t> new_limit(0);
On 2016/11/22 16:06:39, Jorge Lucangeli Obes wrote:
> They cannot both be argument index 0, can they?
> 
> int prlimit(pid_t pid, int resource, const struct rlimit *new_limit, struct
> rlimit *old_limit);
> 
> const Arg<pid_t> pid(0);
> const Arg<intptr_t> new_limit(2);
> 
>
https://codesearch.chromium.org/chromium/src/sandbox/linux/bpf_dsl/bpf_dsl.h?...
> for reference.

https://codesearch.chromium.org/chromium/src/sandbox/linux/bpf_dsl/bpf_dsl.h?...

  // Initializes the Arg to represent the |num|th system call
  // argument (indexed from 0), which is of type |T|.

I read this as "the |num|th ... argument which is of type |T|" =>
  f(T1 a, T2, b, T1 c, T2 d)

So, Arg<T2> d(1) would be |d|.

I guess the ',' in the documentation is significant :-).


Will fix.

[Daniel Kurtz, 2016-11-25 03:36:22]

The CQ bit was checked by djkurtz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-25 03:36:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-25 04:20:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-25 04:20:04]

Dry run: This issue passed the CQ dry run.

[Jorge Lucangeli Obes, 2016-11-28 15:10:04]

lgtm w/nits.

https://codereview.chromium.org/2484393004/diff/60001/sandbox/linux/seccomp-b...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/2484393004/diff/60001/sandbox/linux/seccomp-b...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:367: //
Only allow 'get' operations, and only for the current process
Nit: end with period.

[Daniel Kurtz, 2016-11-28 18:38:44]

https://codereview.chromium.org/2484393004/diff/60001/sandbox/linux/seccomp-b...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/2484393004/diff/60001/sandbox/linux/seccomp-b...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:367: //
Only allow 'get' operations, and only for the current process
On 2016/11/28 15:10:04, Jorge Lucangeli Obes wrote:
> Nit: end with period.

Done.

[Daniel Kurtz, 2016-11-28 18:39:09]

The CQ bit was checked by djkurtz@chromium.org

[Daniel Kurtz, 2016-11-28 18:39:09]

The patchset sent to the CQ was uploaded after l-g-t-m from rickyz@chromium.org,
jorgelo@chromium.org
Link to the patchset: https://codereview.chromium.org/2484393004/#ps80001
(title: "Add '.' to comment")

[commit-bot: I haz the power, 2016-11-28 18:39:53]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-28 20:41:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-28 20:41:36]

Try jobs failed on following builders:
  blimp_linux_dbg on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_clobber_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no
build URL)

[Daniel Kurtz, 2016-11-29 03:32:33]

The CQ bit was checked by djkurtz@chromium.org

[commit-bot: I haz the power, 2016-11-29 03:32:53]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-29 03:38:58]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1480390353142990,
"parent_rev": "f2af0567b2f3679f048d17ffa36bf35176e2bdf6", "commit_rev":
"95f4d35b55e8a60087b1d5935116f53568e42dea"}

[commit-bot: I haz the power, 2016-11-29 03:39:23]

Description was changed from

==========
From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier
==========

to

==========
From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier
==========

[commit-bot: I haz the power, 2016-11-29 03:39:24]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-11-29 03:43:25]

Description was changed from

==========
From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier
==========

to

==========
From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG=chromium:662450
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier

Committed: https://crrev.com/5ce3b357d4cb9906b57f5758ef271cb69dbb664b
Cr-Commit-Position: refs/heads/master@{#434872}
==========

[commit-bot: I haz the power, 2016-11-29 03:43:26]

Patchset 5 (id:??) landed as
https://crrev.com/5ce3b357d4cb9906b57f5758ef271cb69dbb664b
Cr-Commit-Position: refs/heads/master@{#434872}