Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 701184 - sys-apps/portage: there is no configuration-based means of guaranteeing unprivileged syncing
Summary: sys-apps/portage: there is no configuration-based means of guaranteeing unpri...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Portage team
Depends on:
Reported: 2019-11-26 03:29 UTC by Kerin Millar
Modified: 2019-11-26 03:29 UTC (History)
0 users

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 Kerin Millar 2019-11-26 03:29:25 UTC

Portage sniffs the ownership of an existing repo directory to decide under which account it should spawn certain sub-processes. If the directory does not exist, the root context is assumed.

From the standpoint of security and safety, I want for portage to adhere fully to the implications of requesting "user" syncing and never to spawn external utilities as root, be they git, rsync or anything else. No exceptions. Having the existing filesystem metadata - or absence thereof - inform any policy that carries security implications seems sloppy and makes it harder to ensure predictable, consistent behaviour.

I would also point out that this behaviour is needlessly divergent from userfetch. For example, portage will happily create a new DISTDIR that can be written to be portage and avoid spawning FETCH_COMMAND as root, provided that FEATURES="userfetch" is in effect. That's much better.


Method 1:

1) Rename or delete the location of the gentoo repo so that it must be created anew
2) emerge --sync
3) Observe that the emaint-controlled subprocess is executed with root privileges despite FEATURES="usersync" being effective
4) Observe that the tree is root:root owned, which is a counter-intuitive outcome

Method 2:

1) Take a gentoo repo that is owned by portage:portage throughout
2) chown the top-level directory to root:root
3) emerge --sync
4) Observe that the emaint-controlled subprocess is executed with root privileges despite FEATURES="usersync" being effective

In the first case, I would have expected portage to create the directory as portage:portage from the get-go and not to sync as root.

In the second case, I would have expected portage not to try syncing as root. Ending up with mixed ownership isn't a great outcome either. I've unwittingly had that happen to me a few times and have seen people come into #gentoo with that problem, from time to time. I'd rather it just bailed out on EACCES/EPERM.


In my opinion, the behaviour of observing the ownership of ${repository_location} is a bad design. I believe it would be more natural for the "usersync" option to mean exactly what it implies: for syncing operations always to be performed as an unprivileged user. In fact, the idea that portage will assume the privileges of whichever user happened to own the directory at the time is a little unsettling. I can't imagine that wanting portage to adopt the identity of a non-root user other than "portage" is anything but an edge case. Even then, it could just as well be a make.conf setting, such as SYNC_USER  - defaulting to "portage" and only taking effect where usersync is in FEATURES. Ergo, let the user make this decision by way of explicit configuration rather than trying to be clever and guessing the intent from perusing filesystem metadata.

Even if the reader does not agree, the fact that portage assumes the root context in the case the that repo directory does not yet exist remains highly questionable. That would be perfectly understandable in the case that usersync is not in effect. Otherwise, I cannot imagine any scenario in which it would be considered desirable. As an admin of many gentoo machines, I do not want to have to manually create a given repo dir and chown it before the first ever sync, in order to be certain that I am not executing external commands as root and ending up with a root:root owned tree. As portage already has root privileges at that point, it is more than capable of chowning as portage:portage from the outset.

Another option would be to have some sort of "strictusersync" feature, which simply guarantees that privileges are dropped, perhaps unconditionally to the portage user account. While I think that would just be papering over the original design decision, it would at least provide for a definitive means of addressing the issue, without disturbing the status quo.