The following is true for sys-apps/portage-2.1.2_rc3-r5, but I guess earlier versions are affected. An emerge run aborts with lots of sandbox violations if certain conditions (see below) are met: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-games-action_-_bzflag-2.0.8-2874.log" open_wr: /root/.ccache/stats unlink: /root/.ccache/conftest.tmp.nexus.3561.i open_wr: /root/.ccache/conftest.tmp.nexus.3561.i unlink: /root/.ccache/conftest.tmp.nexus.3561.i unlink: /root/.ccache/tmp.cpp_stderr.nexus.3561 [...] This is reproducible with the following preconditions: - CCACHE_DIR (make.conf) is set to a place outside of normal SANDBOX_READ/SANDBOX_WRITE directories (not under /var/tmp or /tmp), for example /root/.ccache - FEATURES (make.conf) does not contain "ccache" - dev-util/ccache is installed - a package is emerged that has a configure script which detects and utilizes ccache by itself, for example games-action/bzflag The effect is that the package's configure script detects ccache and adds it to its Makefiles' CC and/or CXX variables; subsequent make runs start ccache (with $CCACHE_DIR still being set), which in turn tries to write to $CCACHE_DIR. As $CCACHE_DIR is not in $SANDBOX_WRITE (or _READ), a sandbox violation is thrown. This did not happen to default CCACHE_DIR=/var/tmp/ccache users because /var/tmp is normally listed in both $SANDBOX_READ and $SANDBOX_WRITE. Possible countermeasures in ebuild.sh could be an unconditional [ -d "$CCACHE_DIR" ] && addwrite "$CCACHE_DIR" (solar suggested this on #gentoo-portage) and/or if hasq ccache ${FEATURES} ; then [...] else export CCACHE_DISABLE=1 fi (my own suggestion).
(In reply to comment #0) > - a package is emerged that has a configure script which detects and utilizes > ccache by itself, for example games-action/bzflag Generally, we frown on configure scripts that do automatic things based on the environment like that. If one has FEATURES="-ccache", shouldn't the ebuild respect that and disable it?
Well, that was solar's first comment, too. But patching ccache utilization out of every configure script out there could turn into quite some work, I think, and the suggested ebuild.sh modifications would take care of this very well, either.
(In reply to comment #2) > Well, that was solar's first comment, too. But patching ccache utilization out > of every configure script out there could turn into quite some work, That depends on how common it is. > I think, > and the suggested ebuild.sh modifications would take care of this very well, > either. I suppose if CCACHE_DIR is exported in the environment then it's a pretty good assumption that the user wants to use it though. I still don't like it but if it's a common problem with lots of configure scripts then I guess we should do it.
(In reply to comment #0) > if hasq ccache ${FEATURES} ; then > [...] > else > export CCACHE_DISABLE=1 > fi > > (my own suggestion). That's done in svn r5302. Thanks.
This has been released in 2.1.2_rc3-r6.
