Summary: | sandbox: whitelist /dev/stderr, stdin, stdout | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ed Catmur <ed> |
Component: | Sandbox | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic-t-412311-start-0-postdays-0-postorder-asc-highlight-.html | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=922960 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 115839 |
Description
Ed Catmur
2005-12-15 06:09:35 UTC
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. |