Allow the seccomp sandbox to be enabled, even if the suid sandbox has...

Allow the seccomp sandbox to be enabled, even if the suid sandbox has
already put a chroot() jail around it. The only tricky part is access
to /proc/self/maps, but we can safely pass in an open file descriptor.

BUG=26527
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=31372

[Markus (顧孟勤), 2009-11-07 02:41:39]

This changelist looks more intimidating than it really is -- I hope. The bulk of
the change is a refactoring for all accesses to /proc. We now only ever access
/proc/self/maps, and we allow this file descriptor to be passed into the
sandbox.

It turns out that it is sufficient to lseek() back to the beginning of the
/proc/self/maps file in order to refresh its contents. That makes our life much
easier.

[agl, 2009-11-07 05:52:02]

LGTM

http://codereview.chromium.org/371047/diff/1/22
File chrome/browser/zygote_main_linux.cc (right):

http://codereview.chromium.org/371047/diff/1/22#newcode16
Line 16: 
extra blank line.

http://codereview.chromium.org/371047/diff/1/22#newcode56
Line 56: static int  g_proc_fd = -1;
s/  / /

http://codereview.chromium.org/371047/diff/1/12
File sandbox/linux/seccomp/securemem.cc (right):

http://codereview.chromium.org/371047/diff/1/12#newcode27
Line 27: for (char buf;
char buf;
do {
  alive = read(parentMapsFd, &buf, 1);
} while (alive < 0 && errno == EINTR);