The issue out here was pointed out to me by Martin Väth. Long story short, Portage w/ userpriv does all its building as portage:portage, and afterwards fixes portage ownership to root. This generally works but it means that package can't install files owned by :portage. Paludis solves this quite simply -- it uses a separate paludisbuild user/group. If Portage used a similar user/group, it could maintain the behavior of fixing ownership of the user/group used for building while keeping portage ownership intact. It could also improve the separation between access to package manager resources (i.e. being in :portage group) and dedicated build user/group isolation.
If we're going to introduce a new user/group for build purposes, then we should probably define what the old portage user/group will be used for, if anything.
(In reply to Michał Górny from comment #0) > It could also improve the separation between access to package manager > resources (i.e. being in :portage group) and dedicated build user/group > isolation. Okay, so I guess the old "portage" user won't really be needed anymore, and the portagebuild user will be in the old "portage" group.
Well, I know that some users are using :portage group to restrict access to Portage-related resources (especially ebuilds, maybe also distfiles and packages). eix is using that group to control access to the cache directory.
A simpler fix would to be change the UID/GID remapping code so what it only affects files have the same UID as the "portage" user, since there's really no valid reason for anything to be owned by that user. So, ownership of root:portage files would be preserved.
Patch posted for review: https://archives.gentoo.org/gentoo-portage-dev/message/7eea2fae7e7e9080620203207d4b187e https://github.com/gentoo/portage/pull/73
This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=f479a4cdcac5db92231f489f232f10eb934c6f12
Fixed in portage-2.3.3.
(In reply to Zac Medico from comment #4) > A simpler fix would to be change the UID/GID remapping code so what it only > affects files have the same UID as the "portage" user, since there's really > no valid reason for anything to be owned by that user. So, ownership of > root:portage files would be preserved. PMS says (https://projects.gentoo.org/pms/7/pms.html#x1-14400013.3.1): "Any file whose group is the primary group of the user used to perform the build must have its group be that of the root user." So a file owned by root:portage must be changed to root:root. This was still fine in portage-2.3.2 but is broken since portage-2.3.3. (In reply to Zac Medico from comment #6) > This is in the master branch: > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=f479a4cdcac5db92231f489f232f10eb934c6f12 Reverting this commit fixes it. Reopening.
We could simply chown all the files from portage:portage to root:root prior to src_install, which will effectively erase all traces of the "user used to perform the build" mentioned by PMS. If we introduce a separate "user used to perform the build" then the result will be the same.
(In reply to Zac Medico from comment #9) > We could simply chown all the files from portage:portage to root:root prior > to src_install, which will effectively erase all traces of the "user used to > perform the build" mentioned by PMS. If we introduce a separate "user used > to perform the build" then the result will be the same. That looks somewhat brittle. I've seen ebuilds that tar things up in one phase and untar them in another phase. These won't be caught by chown. IMHO the originally suggested separate user and group would be the cleanest solution. These could even be shared between package managers.
(In reply to Ulrich Müller from comment #10) > That looks somewhat brittle. I've seen ebuilds that tar things up in one > phase and untar them in another phase. These won't be caught by chown. Yeah that's true enough. > IMHO the originally suggested separate user and group would be the cleanest > solution. These could even be shared between package managers. Sounds good.
I'd like to get this fixed in a way that complies with PMS. We'll have to check and see what the old "portage" user is actually good for other than building stuff. It may be that we should introduce a different user for the other non-build stuff.
Maybe we can use the "wheel" group for some things that the "portage" group is currently used for. For example, GLEP 42 currently specifies that /var/lib/gentoo/news should be writable by the "portage" group, but it seems like the "wheel" group would fit well here.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=294f1a18f3271f7d506d346c2a514a2afa6ce8ec commit 294f1a18f3271f7d506d346c2a514a2afa6ce8ec Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2018-06-23 09:22:18 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-06-23 09:22:18 +0000 Revert "_post_src_install_uid_fix: allow files with portage group permissions (bug 600804)" This reverts commit f479a4cdcac5db92231f489f232f10eb934c6f12. Acked by zmedico in #gentoo-portage. Bug: https://bugs.gentoo.org/600804 pym/portage/package/ebuild/doebuild.py | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
(In reply to Zac Medico from comment #12) > It may be that we should introduce a different user for the > other non-build stuff. For non-build stuff there are a lot of other tools. It is much less convenient to require changes of all of these (and BTW also user configurations, e.g. when users are put into the portage group to give them certain administration rights) than to introduce a new user for building: Building is more or less portage-internal, only, and having a new user here would hardly require changes for other tools or user configuration.
It would be nice to be able to dynmically allocate disposable build users. For example, systemd has a feature like this for services: http://0pointer.net/blog/dynamic-users-with-systemd.html
My plan is to create a plugin system for dynamic user allocators, and initially the default plugin will simply return the normal "portage" user. After that we can add plugins that implement true dynamic user allocation. One such plugin might use nss-systemd internally.
Before you go too far with crazy ideas that serve no purpose except 'being cool': 1. I really do think it'd be nice to implement a *simple working solution* first which is using a different user for builds. 2. I would like to remind you that Portage uses shared files that need to be owned by user performing the build (e.g. '.distcc'), and which obviously can't sanely work when you're using multiple users.
(In reply to Michał Górny from comment #18) > Before you go too far with crazy ideas that serve no purpose except 'being > cool': > > 1. I really do think it'd be nice to implement a *simple working solution* > first which is using a different user for builds. That's precisely why my intention is for the initial default user allocator to simply return the normal "portage" user (or some other static user). > 2. I would like to remind you that Portage uses shared files that need to be > owned by user performing the build (e.g. '.distcc'), and which obviously > can't sanely work when you're using multiple users. Yeah we'll have to work that out before we enable dynamic user allocation.
This patch introduces the separate build user so that we can begin migrating the internals to use it: https://github.com/gentoo/portage/pull/329 https://archives.gentoo.org/gentoo-portage-dev/message/ed2bc34798517c470dc018a06a935828