Linux sandbox: plumb timezone calls through the sandbox

Linux sandbox: plumb timezone calls through the sandbox

The localtime (and localtime_r) functions try to access /etc/localtime
in the filesystem. For sandboxed renderers, this fails, the the
functions default to a UTC timezone.

These functions are called from within WebCore and V8 and there's no
clean way to patch the source code in place to do a hairpin turn and
manage an IPC. Additionally, we cannot overwrite the calls with the
usual symbol resolution procedures since the same chrome binary must
serve as both the unsandboxed browser and sandboxed renderer.

Thus we patch the GOT at runtime if we find, in the zygote process,
that we are sandboxed.

BUG=16800
TEST=Run javascript:alert(new Date().getTimezoneOffset()) in a sandboxed renderer. The resulting timezone offset (in minutes) should be correct for the local timezone.

[Evan Martin, 2009-07-20 18:51:17]

+ some gents who understand guts

[Evan Martin, 2009-07-20 18:57:25]

What I had said to agl: isn't there some way to hook functions at the linker
level?  The assembly stuff feels fragile to me, though I don't expect it to
really change...

http://codereview.chromium.org/155783/diff/9/11
File chrome/browser/zygote_main_linux.cc (right):

http://codereview.chromium.org/155783/diff/9/11#newcode211
Line 211: uint8_t reply_buf[512];
sizeof(struct tm) here?

[Evan Martin, 2009-07-20 19:02:00]

Also, this hooks glibc in some other way, who knows how crazy it is.

http://bazaar.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.2.head/annot...

[Dean McNamee, 2009-07-21 09:39:21]

Can we cache the results to avoid IPCs?  Do we know how often the timezone is
requested?  I would opt for performance over supporting timezone changes without
restart, but maybe the performance isn't so bad.