Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 578980 - dobin fails with 'Operation not permitted' if ebuild run as unprivileged user
Summary: dobin fails with 'Operation not permitted' if ebuild run as unprivileged user
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-04 05:59 UTC by Michael 'veremitz' Everitt
Modified: 2022-10-20 02:43 UTC (History)
0 users

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 Michael 'veremitz' Everitt 2016-04-04 05:59:42 UTC
Ebuilds using the 'dobin' install function will fail if testing using an unprivileged user, with 'Operation not permitted' at the 'install' stage.

I have tracked this down to https://github.com/gentoo/portage/blob/master/bin/ebuild-helpers/dobin#L24

Do we really need to set owner at this stage, surely it gets correctly assigned when you merge to the live system? All other binaries seem to be copied to the sandbox correctly as the unprivileged user.

I appreciate this is somewhat an edge-case, as final ebuild will only be run as root, but it does generate a false error for testing purposes!
Comment 1 Zac Medico gentoo-dev 2016-04-04 07:11:06 UTC
This already works with FEATURES=fakeroot.

(In reply to Michael Everitt (IRC: veremit) from comment #0)
> Do we really need to set owner at this stage, surely it gets correctly
> assigned when you merge to the live system?

We automatically map PORTAGE_USERNAME and PORTAGE_GRPNAME in the _post_src_install_uid_fix function, so we can safely substitute those when necessary. All other UIDs and GIDs are preserved when the files are merged to the live system.
Comment 2 Ian Delaney (RETIRED) gentoo-dev 2016-04-13 08:23:46 UTC
This to me satisfactorily answers the issue of this bug. I'd suggest adding fakeroot to FEATURES in make.conf and close resolved ? WONTFIX since it is fixable but resolvable via an option already available.
Comment 3 Zac Medico gentoo-dev 2016-04-13 08:36:21 UTC
Well, I like portage to be as tolerant as possible for cases like this. It's very close to how portage is often used in prefix environments (FEATURES=unprivileged is related).

I think what we want it to do here is use PORTAGE_USERNAME and PORTAGE_GRPNAME when we don't have permission to use PORTAGE_INST_UID and PORTAGE_INST_GID. This can be handled on the python side, by dynamically modifying the PORTAGE_INST_UID and PORTAGE_INST_GID variables.
Comment 4 SpanKY gentoo-dev 2016-04-15 02:56:21 UTC
this looks like bug 566614 to me
Comment 5 Zac Medico gentoo-dev 2016-04-15 03:35:25 UTC
(In reply to SpanKY from comment #4)
> this looks like bug 566614 to me

Well, the specific complaint about dobin in comment #0 is much smaller in scope than bug 566614. It's a relatively easy case to handle, and will work fine for a large subset of packages that don't require any special file permission settings.
Comment 6 Michael 'veremitz' Everitt 2016-07-02 16:42:03 UTC
Also applies to dosbin, for reference, but this is probably apparent to the portage team anyway, but adding for completeness.