Dnia 2014-07-08, o godz. 16:17:02
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Tue, 8 Jul 2014, Michał Górny wrote:
> 
> > b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups()
> > to transparently enable group membership for the build process.
> 
> > Advantages:
> 
> > - transparent, relatively simple.
> 
> > Disadvantages:
> 
> > - quite ugly name ;),
> 
> Certainly this can be changed. :)
> 
> > - doesn't cover other uses of FEATURES=userpriv.
> 
> Which ones? Are there examples for such uses in the Portage tree?

I meant RESTRICT=userpriv, of course :).

So far most of the 'why are you blocking userpriv?' bugs lie with no
answer but there's already the case of fatsort which tests loop-mount
a VFAT filesystem and use it to run tests. This effectively makes it
require CAP_SYSADMIN.

Of course, we could discuss that the test is very wrong to do that,
that it fails when there's no VFAT support in kernel etc. I'd love to
see upstream switching to some userspace FAT manipulation tools
(mtools, for example) but it's not my call.

> > c) 'esudo' helper [3]. This is a more generic form of (2), with
> > support for other potential privilege changes.
> 
> > [...]
> 
> > Disadvantages:
> 
> > - hard to implement -- especially if we want to make it capable of
> >   running bash functions.
> 
> Any idea how to implement it? Does it imply adding app-admin/sudo to
> the system set?

I don't think we'd use the reference 'sudo' impl. Rather some
in-portage helper, possibly setuid. Or portage's IPC but that would
imply running the command in an isolated environment (possibly
beneficial).

> > What do you think? Do you have other ideas?
> 
> Looking at the bugs that you have filed, it looks like most ebuilds
> using userpriv restriction could be fixed, without any additional
> support added to the package manager.
> 
> How many ebuilds will be left, after doing these fixes? Is it really
> worth the effort then?

What kind of fixes do you mean? Killing the games group? Adding ACLs
for portage user?

Please also remember that the bugs don't cover all cases. For example,
many CUDA/nvidia cases use solution alike (1) at the moment.

-- 
Best regards,
Michał Górny