As well as the linked URL, there have on the forums been sporadic instances of ebuilds borking with sandbox vios on /dev/stderr. It's difficult to tell what is trying to write to /dev/stderr, but adding addwrite /dev/stderr to /etc/portage/bashrc lets the ebuild complete, suggesting it can't be anything important. I suggest sandbox should whitelist /dev/std{in,out,err}. It can't hurt, right?
it isnt sporadic at all, everyone who is seeing /dev/stderr sandbox errors have not updated their portage tree, the bug has been fixed in the eclass already
When I was troubleshooting bug 115434 I noticed that redirection to /dev/stderr (flag-o-matic.eclass, for example) results in "Permission denied" errors when FEATURES="userpriv" is enabled (not because of sandbox, but because of dropped privileges. This leads me to wonder why flag-o-matic.eclass doesn't use >&2 instead of >/dev/stderr, since >&2 seems to work with with dropped privileges while >/dev/stderr does not.
Apparently there's some kernel magic that redirects /dev/std{in,out,err}.. I kind of wonder what's there when those files are closed. Someone more knowledgeable than me: are these safe to add for the general case?
yes
Done. :)
Released in 2.1_pre2.