Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 657582 - sys-apps/portage: keeps wrongly updating permissions when CCACHE_DIR overriden by bashrc
Summary: sys-apps/portage: keeps wrongly updating permissions when CCACHE_DIR override...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Keywords: PATCH
Depends on:
Reported: 2018-06-08 07:28 UTC by Michał Górny
Modified: 2021-07-24 13:10 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-06-08 07:28:39 UTC
I have the following snippet in /etc/portage/bashrc:

if [[ ${FEATURES} == *ccache* && ${EBUILD_PHASE_FUNC} == src_* ]]; then
	if [[ ${CCACHE_DIR} == /var/cache/ccache ]]; then
		export CCACHE_DIR=/var/cache/ccache/${CATEGORY}/${PN}:${SLOT%/*}
		mkdir -p "${CCACHE_DIR}" || die

Now, if I install a new package that's not yet in ccache (i.e. overriden dir does not exist), Portage tries to update permissions... on /var/cache/ccache.  Which is completely unnecessary because the permissions of that directory are fine, and it takes a lot of time because it's huge.

If I create and chown the overriden dir beforehand, Portage doesn't do that.  My guess is that the two paths are getting mixed up somewhere, and one is used for the check but the other for the update.
Comment 1 Zac Medico gentoo-dev 2018-12-12 04:06:25 UTC
Should we add a FEATURES="cache-permission-adjust" flag that people can use to enable or disable the automatic adjustment?
Comment 3 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2018-12-12 06:49:05 UTC
I've got a partial strategy to avoid this problem that *kinda* works.

Basically, instead of nesting all the custom CCACHE_DIR nodes under the dir portage considers to be CCACHE_DIR, make CCACHE_DIR somewhere out-of-place that stops portage tinkering.

For me, I opted to make it:


Because something in portage sucks and despite the logic used in this bug, ccache still gets invoked occasionally outside the parameters and in odd permissions states, and you get "raw" ccache behaviour.

Making this work requires a bit of tinkering, because well, the design in this document relies on the *original* CCACHE_DIR being in the SANDBOX_WRITE list.

So also having to add the stanza:

    SANDBOX_WRITE="${SANDBOX_WRITE}:/var/cache/ccache" is necessary to make this work.

And of course, replicate this logic to the if [[ ${CCACHE_DIR} == ]] statement.

This way at least, when portage invokes its top-level "fix all the perms", it only does a perm fix on the crufty CCACHE_DIR it knows about (Which will be very small), not the millions of files under custom tricks. ( For me, so far its just a stub ccache tree containing only stats entries )

And if you get extra lucky, it might fix broken versions of custom CCACHE_DIR paths generated by bashrc 

Comment 4 interruptinuse 2021-07-24 13:10:44 UTC
The patch proposed[1] by Zac has been useful to me personally: it's not obvious how to set up a system-wide ccache with group access (e.g. root:ccache ownership, 002 umask), because emerge keeps adjusting ownership to portage in every time, which makes non-root builds fail.