Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 600804 - sys-apps/portage: Introduce a separate build user/group to avoid conflicts with 'portage' uid/gid
Summary: sys-apps/portage: Introduce a separate build user/group to avoid conflicts wi...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks: 604854
  Show dependency tree
 
Reported: 2016-11-25 14:55 UTC by Michał Górny
Modified: 2024-03-03 22:38 UTC (History)
4 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 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-11-25 14:55:16 UTC
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.
Comment 1 Zac Medico gentoo-dev 2016-11-25 20:42:28 UTC
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.
Comment 2 Zac Medico gentoo-dev 2016-11-25 20:45:52 UTC
(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.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-11-25 22:18:49 UTC
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.
Comment 4 Zac Medico gentoo-dev 2016-11-29 20:09:25 UTC
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.
Comment 7 Zac Medico gentoo-dev 2017-02-10 18:53:54 UTC
Fixed in portage-2.3.3.
Comment 8 Ulrich Müller gentoo-dev 2018-06-20 22:23:21 UTC
(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.
Comment 9 Zac Medico gentoo-dev 2018-06-20 23:12:12 UTC
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.
Comment 10 Ulrich Müller gentoo-dev 2018-06-21 14:37:20 UTC
(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.
Comment 11 Zac Medico gentoo-dev 2018-06-23 08:02:43 UTC
(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.
Comment 12 Zac Medico gentoo-dev 2018-06-23 08:15:05 UTC
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.
Comment 13 Zac Medico gentoo-dev 2018-06-23 08:43:18 UTC
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.
Comment 14 Larry the Git Cow gentoo-dev 2018-06-23 09:24:03 UTC
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(-)
Comment 15 Martin Väth 2018-06-23 09:33:09 UTC
(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.
Comment 16 Zac Medico gentoo-dev 2018-06-23 11:17:11 UTC
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
Comment 17 Zac Medico gentoo-dev 2018-06-24 03:27:52 UTC
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.
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-06-24 21:18:59 UTC
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.
Comment 19 Zac Medico gentoo-dev 2018-06-24 21:22:59 UTC
(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.
Comment 20 Zac Medico gentoo-dev 2018-06-25 01:03:41 UTC
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