Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 284775 - sys-apps/portage-2.1.16.13 userpriv breaks shared ccache
Summary: sys-apps/portage-2.1.16.13 userpriv breaks shared ccache
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-13 15:54 UTC by Arthur Hagen
Modified: 2014-10-24 08:24 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arthur Hagen 2009-09-13 15:54:11 UTC
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.
Comment 1 Marcin Mirosław 2014-10-24 08:12:43 UTC
Is this bug still valid?
Comment 2 Zac Medico gentoo-dev 2014-10-24 08:24:03 UTC
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.