TMPDIR is currently set to /var/tmp/portage/$CATEGORY/$P/temp during emerge. This directory is created group writeable. I have setup my hardened kernel to deny exec in untrusted directories. Thus it prevents execution of scripts there: grsec: From 127.0.0.6: denied untrusted exec (due to file in group-writable directory) of /var/tmp/portage/media-video/ffmpeg-0.10.6/temp/ffconf.ZLmMqQZ9.sh by /var/tmp/portage/media-video/ffmpeg-0.10.6/temp/ffconf.ZLmMqQZ9.sh[configure:1251] uid/euid:250/250 gid/egid:250/250, parent /var/tmp/portage/media-video/ffmpeg-0.10.6/work/ffmpeg-0.10.6/configure[configure:772] uid/euid:250/250 gid/egid:250/250 Is it possible / sensible to remove group-write access from that directory (i.e. $TMPDIR)? Is there a valid usecase for the portage group writing to the ./temp dir? Reproducible: Always
(In reply to comment #0) > I have setup my hardened kernel to deny exec in untrusted directories. I thought this was related to TPE, but the hardened kernel seems to do this for all users (I excluded the portage user from TPE using GRKERNSEC_TPE_TRUSTED_GID). Thus I assume this problem affects all hardened users.
The "portage" group is considered trusted. It's intended to grant write access to trusted users. For example, a trusted user might call ebuild(1) with sudo just for specific phases like pkg_setup that need special privileges, and then call ebuild(1) again without sudo. In this case, belonging to the "portage" group grants the necessary privileges to do this. It's also used to grant access to the special "portage" user that's used to implement FEATURES=userpriv. No untrusted users should be added to the "portage" group. We have a warning about this, as shown in bug 149062, comment #15.
(In reply to comment #2) > The "portage" group is considered trusted. It's intended to grant write > access to trusted users. Thanks for that explanation. So I need to figure out why the hardened kernel enforces no-group-writability here. I'll report back once I know.
After reading the grsec patch it became obvious: The issue stems from a misunderstanding of the CONFIG_GRKERNSEC_TPE_ALL option.
(In reply to Dennis Schridde from comment #4) > After reading the grsec patch it became obvious: The issue stems from a > misunderstanding of the CONFIG_GRKERNSEC_TPE_ALL option. Not exactly invalid, but we don't have to reopen this. Take a look at the solution in bug #519566.
