Hacker News Reader

Comment by evmar | Hacker News Reader

One FD_CLOEXEC-related bug that got us in Chrome: on Linux, while we were careful to close any open fds when spawning a subprocess, the GTK IME ("input method editor", modules to facilitate typing Japanese etc.) could itself spawn subprocesses in response to innocuous calls (like user keystrokes). Those subprocesses could then inherit (and keep open) fds we wanted to be closed.

View on HN

Oh hey, any chance you could explain this bit of the /usr/bin/google-chrome script I've always wondered about? (Sadly, the bug is RVG.)

   # Sanitize std{in,out,err} because they'll be shared with untrusted child
   # processes (http://crbug.com/376567).
   exec < /dev/null
   exec > >(exec cat)
   exec 2> >(exec cat >&2)

Somehow child processes can abuse stdin/stderr/stdout in ... creative ways?

Funny. /usr/bin/chromium shows nothing like that.

I'm wondering why these launchers differ so much.

/usr/bin/google-chrome is written by Google and analyzed by the security team. /usr/bin/chromium is written by enthusiasts (the distro's package author).

Reply on news.ycombinator.com