On a system with a global shared ccache, common practice (as e.g. Fedora does by default) is to create a ccache group, add all users who should use the cache to this group, and set the global ccache directory to g+w,g+s. However, if you add portage to a global ccache group, userpriv outsmarts itself, and changes the group on the CCACHE_DIR directory to portage, despite already having write access to it. This breaks the global ccache for users who aren't in the portage group. There is no good workaround for this. - Using "portage" as the global ccache group means giving additional access to users beyond just the cache. - Using separate caches for portage means the rest of the system means users (including root) won't get the correct cached results when troubleshooting why something in /var/tmp/portage/ didn't compile. Plus, there may other reasons for wanting a shared cache, like space issues, backup exclusions, NAS use, or other. Recommendation: portage should check whether it has write access to the CCACHE_DIR directory, and if so, leave the ownership alone. A cache that is 2770 root:somegroup should be perfectly acceptable, as long as portage is a member of the "somegroup" group.
Is this bug still valid?
It looks like the code in pym/portage/package/ebuild/prepare_build_dirs.py still changes CCACHE_DIR permissions if the directory is not writable by the "portage" group. I think we should change it to use something like the _userpriv_test_write_file function that we have in pym/portage/package/ebuild/fetch.py. This function spawns a process as the portage user, and tests if it can write a file.