Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 566614 - [Future EAPI] allow src_install to run as a single non-root user
Summary: [Future EAPI] allow src_install to run as a single non-root user
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2015-11-23 11:12 UTC by SpanKY
Modified: 2019-08-25 19:15 UTC (History)
2 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 SpanKY gentoo-dev 2015-11-23 11:12:11 UTC
portage has userfetch/userpriv features so that most of the src phases can run w/out requiring root.  this works for the vast majority of packages (grep for RESTRICT=userpriv to find a few hold outs).

unfortunately, the same cannot be said for install.  this is for two reasons:
(1) some packages will `chown` or `chgrp` files during e.g. `make install`.  but if you try to mitigate this, you run into the next issue.
(2) `fowners` and `fperms +s` fundamentally assume you're running w/privs

we could RESTRICT these too, but where's the fun in that.  what if we made fowners and fperms command queue the operations and then have the PM dequeue them once src_install finishes ?
Comment 1 Zac Medico gentoo-dev 2015-11-23 17:46:35 UTC
(In reply to SpanKY from comment #0)
> we could RESTRICT these too, but where's the fun in that.  what if we made
> fowners and fperms command queue the operations and then have the PM dequeue
> them once src_install finishes ?

What about makefiles that call install, chown, and chmod directly though? Should we use wrappers to intercept those calls and queue them too?
Comment 2 SpanKY gentoo-dev 2015-11-24 20:23:11 UTC
(In reply to Zac Medico from comment #1)

i referenced these in (1).  so far my experience has been that it's not that common in practice.  i think patching the build and having the ebuild call fowners/fperms itself is better.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-24 20:33:08 UTC
What about build systems that are not built on top of shell utilities? Like those written in Python that directly call os.*().
Comment 4 SpanKY gentoo-dev 2015-11-24 21:29:14 UTC
(In reply to Michał Górny from comment #3)

i assume that's in response to Zac's proposal, but obviously we'd have to patch them too to not make such calls and have the ebuild use fowners/fperms.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-24 21:38:02 UTC
Thank you but no, I'm against expecting people to create and maintain forever huge patches to build systems. You're trying to do this from the wrong end. Or rather than wrong, the completely unpractical one. I'd rather try to approach this via sandbox.
Comment 6 SpanKY gentoo-dev 2015-11-24 22:35:54 UTC
(In reply to Michał Górny from comment #5)

except that doesn't work for all systems.  we support Gentoo on more than just Linux which is about the only place where sandbox works reliably.  we also support systems that have no root access at all.

if a few packages need to carry patches so the vast majority work well, then so be it.  we shouldn't be crippling the system so a few misbehaving packages get to continue to limp forever.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-24 22:42:38 UTC
I'd really prefer numbers over theory here. Because I believe we both know how many people can write good build systems, and how many people believe all current build systems are wrong and a new one should be written with no regard to all experiences so far.
Comment 8 Ulrich Müller gentoo-dev 2015-11-24 22:49:24 UTC
(In reply to SpanKY from comment #6)
> we shouldn't be crippling the system so a few misbehaving packages
> get to continue to limp forever.

I cannot see anything wrong or misbehaving in a build system that calls chown or chmod during make install.
Comment 9 SpanKY gentoo-dev 2015-11-24 23:34:07 UTC
(In reply to Michał Górny from comment #7)

which is why i already sent a patch to the portage list

(In reply to Ulrich Müller from comment #8)

we're talking specifically about the +s bits, not all chown calls.  even then, we don't need to do so as we can the PM simply save/restore the mode bits when applying the delayed ownership.

as for packages calling `chown` or `chgrp` unconditionally, yes, those are crap packages.  being unable to build/install a package as non-root is a strong indication of crap.
Comment 10 Joakim Tjernlund 2015-11-25 00:38:22 UTC
(In reply to SpanKY from comment #0)
> portage has userfetch/userpriv features so that most of the src phases can
> run w/out requiring root.  this works for the vast majority of packages
> (grep for RESTRICT=userpriv to find a few hold outs).
> 
> unfortunately, the same cannot be said for install.  this is for two reasons:
> (1) some packages will `chown` or `chgrp` files during e.g. `make install`. 
> but if you try to mitigate this, you run into the next issue.
> (2) `fowners` and `fperms +s` fundamentally assume you're running w/privs
> 
> we could RESTRICT these too, but where's the fun in that.  what if we made
> fowners and fperms command queue the operations and then have the PM dequeue
> them once src_install finishes ?

Not sure what this adds that fakeroot doesn't already solve?
Comment 11 SpanKY gentoo-dev 2015-11-25 03:34:58 UTC
(In reply to Joakim Tjernlund from comment #10)

fakeroot doesn't really solve anything.  it has the same limitations i already listed for sandbox.
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-25 07:54:23 UTC
I really don't see this. Gentoo is really supposed to follow upstream, and optimize for the common case when possible. As I see it, you are trying to make life a lot harder for a number of developers for a corner case of systems that are barely supported by Gentoo.

I don't really want to be fixing a lot of build systems, indefinitely and repeatedly. What I'm really supposed to say upstream? 'Here's a patch making your "make install" work as regular user, please apply it and tell your users that from now on, they must manually set all ownerships and everything unless they install via distro which hopefully will do that for them'?

There is a number things that can happen during src_install(), require extended permissions and filesystem features. Some things that come to my head:

- hardlinks, reflinks,

- ACLs,

- capabilities,

- user xattrs.

What I'd really prefer to see if someone came up with good virtualization for all of that to work reliably without root and without filesystem support, be stored in binary packages properly and restored upon merge.

Most of the POSIX-ish systems should provide some means of doing so. Of course, it's some extra work for each one of them.
Comment 13 Ulrich Müller gentoo-dev 2015-11-25 09:02:13 UTC
What about error behaviour? For example, would your queueing fowners and fperms check if all files exist, at the time these functions are called?
Comment 14 Joakim Tjernlund 2015-11-26 09:26:10 UTC
(In reply to SpanKY from comment #11)
> (In reply to Joakim Tjernlund from comment #10)
> 
> fakeroot doesn't really solve anything.  it has the same limitations i
> already listed for sandbox.

Last I used FEATURES=fakeroot I could build binary pkgs and install
files as non root to ROOT=/xxx. binpkgs had the correct owner so if installed
in a real system(as root) files got the correct owners etc.

One thing not working merging into ROOT=/xxx as non root was the
post_install trying to add users/groups