| 1 |
>>>>> On Tue, 8 Jul 2014, Michał Górny wrote: |
| 2 |
|
| 3 |
> a) explicitly requesting user to alter group membership for the |
| 4 |
> build user. This is already done in some of the CUDA ebuilds. |
| 5 |
|
| 6 |
> [...] |
| 7 |
|
| 8 |
This doesn't work out of the box for users, therefore it is not really |
| 9 |
a solution. |
| 10 |
|
| 11 |
> b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups() |
| 12 |
> to transparently enable group membership for the build process. |
| 13 |
|
| 14 |
> Advantages: |
| 15 |
|
| 16 |
> - transparent, relatively simple. |
| 17 |
|
| 18 |
> Disadvantages: |
| 19 |
|
| 20 |
> - quite ugly name ;), |
| 21 |
|
| 22 |
Certainly this can be changed. :) |
| 23 |
|
| 24 |
> - doesn't cover other uses of FEATURES=userpriv. |
| 25 |
|
| 26 |
Which ones? Are there examples for such uses in the Portage tree? |
| 27 |
|
| 28 |
> c) 'esudo' helper [3]. This is a more generic form of (2), with |
| 29 |
> support for other potential privilege changes. |
| 30 |
|
| 31 |
> [...] |
| 32 |
|
| 33 |
> Disadvantages: |
| 34 |
|
| 35 |
> - hard to implement -- especially if we want to make it capable of |
| 36 |
> running bash functions. |
| 37 |
|
| 38 |
Any idea how to implement it? Does it imply adding app-admin/sudo to |
| 39 |
the system set? |
| 40 |
|
| 41 |
> What do you think? Do you have other ideas? |
| 42 |
|
| 43 |
Looking at the bugs that you have filed, it looks like most ebuilds |
| 44 |
using userpriv restriction could be fixed, without any additional |
| 45 |
support added to the package manager. |
| 46 |
|
| 47 |
How many ebuilds will be left, after doing these fixes? Is it really |
| 48 |
worth the effort then? |
| 49 |
|
| 50 |
Ulrich |
Archives