1 |
Dnia 2014-07-08, o godz. 16:17:02 |
2 |
Ulrich Mueller <ulm@g.o> napisał(a): |
3 |
|
4 |
> >>>>> On Tue, 8 Jul 2014, Michał Górny wrote: |
5 |
> |
6 |
> > b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups() |
7 |
> > to transparently enable group membership for the build process. |
8 |
> |
9 |
> > Advantages: |
10 |
> |
11 |
> > - transparent, relatively simple. |
12 |
> |
13 |
> > Disadvantages: |
14 |
> |
15 |
> > - quite ugly name ;), |
16 |
> |
17 |
> Certainly this can be changed. :) |
18 |
> |
19 |
> > - doesn't cover other uses of FEATURES=userpriv. |
20 |
> |
21 |
> Which ones? Are there examples for such uses in the Portage tree? |
22 |
|
23 |
I meant RESTRICT=userpriv, of course :). |
24 |
|
25 |
So far most of the 'why are you blocking userpriv?' bugs lie with no |
26 |
answer but there's already the case of fatsort which tests loop-mount |
27 |
a VFAT filesystem and use it to run tests. This effectively makes it |
28 |
require CAP_SYSADMIN. |
29 |
|
30 |
Of course, we could discuss that the test is very wrong to do that, |
31 |
that it fails when there's no VFAT support in kernel etc. I'd love to |
32 |
see upstream switching to some userspace FAT manipulation tools |
33 |
(mtools, for example) but it's not my call. |
34 |
|
35 |
> > c) 'esudo' helper [3]. This is a more generic form of (2), with |
36 |
> > support for other potential privilege changes. |
37 |
> |
38 |
> > [...] |
39 |
> |
40 |
> > Disadvantages: |
41 |
> |
42 |
> > - hard to implement -- especially if we want to make it capable of |
43 |
> > running bash functions. |
44 |
> |
45 |
> Any idea how to implement it? Does it imply adding app-admin/sudo to |
46 |
> the system set? |
47 |
|
48 |
I don't think we'd use the reference 'sudo' impl. Rather some |
49 |
in-portage helper, possibly setuid. Or portage's IPC but that would |
50 |
imply running the command in an isolated environment (possibly |
51 |
beneficial). |
52 |
|
53 |
> > What do you think? Do you have other ideas? |
54 |
> |
55 |
> Looking at the bugs that you have filed, it looks like most ebuilds |
56 |
> using userpriv restriction could be fixed, without any additional |
57 |
> support added to the package manager. |
58 |
> |
59 |
> How many ebuilds will be left, after doing these fixes? Is it really |
60 |
> worth the effort then? |
61 |
|
62 |
What kind of fixes do you mean? Killing the games group? Adding ACLs |
63 |
for portage user? |
64 |
|
65 |
Please also remember that the bugs don't cover all cases. For example, |
66 |
many CUDA/nvidia cases use solution alike (1) at the moment. |
67 |
|
68 |
-- |
69 |
Best regards, |
70 |
Michał Górny |