1 |
On 21/07/13 02:25 PM, Zac Medico wrote: |
2 |
> On 07/21/2013 03:53 AM, Pacho Ramos wrote: |
3 |
>> El mar, 03-07-2012 a las 10:02 +0200, Michał Górny escribió: |
4 |
>>> On Mon, 02 Jul 2012 13:45:26 -0700 |
5 |
>>> Zac Medico <zmedico@g.o> wrote: |
6 |
>>> |
7 |
>>>> On 07/02/2012 01:36 PM, vivo75@×××××.com wrote: |
8 |
>>>>> Il 02/07/2012 22:01, Zac Medico ha scritto: |
9 |
>>>>>> On 07/02/2012 12:48 PM, Pacho Ramos wrote: |
10 |
>>>>>>> El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió: |
11 |
>>>>>>>> Hi, |
12 |
>>>>>>>> |
13 |
>>>>>>>> In case you aren't familiar with FEATURES=userpriv, here's the |
14 |
>>>>>>>> description from the make.conf(5) man page: |
15 |
>>>>>>>> |
16 |
>>>>>>>> Allow portage to drop root privileges and compile packages as |
17 |
>>>>>>>> portage:portage without a sandbox (unless usersandbox is also |
18 |
>>>>>>>> used). |
19 |
>>>>>>>> |
20 |
>>>>>>>> The rationale for having the separate "usersandbox" setting, to |
21 |
>>>>>>>> enable use of sys-apps/sandbox, is that people who enable |
22 |
>>>>>>>> userpriv sometimes prefer to have sandbox disabled in order to |
23 |
>>>>>>>> slightly improve performance. However, I would recommend to |
24 |
>>>>>>>> enable usersandbox by default, for the purpose of logging |
25 |
>>>>>>>> sandbox violations. |
26 |
>>>>>>>> |
27 |
>>>>>>>> Note that ebuilds can set RESTRICT="userpriv" if they require |
28 |
>>>>>>>> superuser privileges during any of the src_* phases that |
29 |
>>>>>>>> userpriv affects. |
30 |
>>>>>>>> |
31 |
>>>>>>>> I've been using FEATURES="userpriv usersandbox" for years, and I |
32 |
>>>>>>>> don't remember experiencing any problems because of it, so I |
33 |
>>>>>>>> think that it would be reasonable to have it enabled by default. |
34 |
>>>>>>>> Objections? |
35 |
>>>>>>> Looks like non important problems arised and, then, these could |
36 |
>>>>>>> probably be enabled by default, no? :) |
37 |
>>>>>> I'm not sure about the best way to handle migration for directories |
38 |
>>>>>> inside $DISTDIR that are used by live ebuilds, since src_unpack |
39 |
>>>>>> will run with different privileges when userpriv is enabled. |
40 |
>>>>> tell the user to chown/remove the files/directories if and when |
41 |
>>>>> needed, |
42 |
>>>> |
43 |
>>>> How should we tell them? Elog message, news item, or both? |
44 |
>>> |
45 |
>>> I think this deserves a news item anyway. |
46 |
>>> |
47 |
>>>>> unless there is a very good reason (try) to automate it. |
48 |
>>>> |
49 |
>>>> I guess something like this might work in pkg_postinst of the portage |
50 |
>>>> ebuild: |
51 |
>>>> |
52 |
>>>> find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R |
53 |
>>>> portage:portage |
54 |
>>> |
55 |
>>> find "$DISTDIR" -maxdepth 1 -type d -uid 0 -exec \ |
56 |
>>> chown -R portage:portage {} + |
57 |
>>> |
58 |
>>>> I would only trigger something like this once, when upgrading from a |
59 |
>>>> version that doesn't have userpriv enabled by default. |
60 |
>>> |
61 |
>>> This will work only for users who actually keep those in DISTDIR. Some |
62 |
>>> of them actually redefine E*_STORE_DIR to a more sane location. But |
63 |
>>> that's probably irrelevant. |
64 |
>>> |
65 |
>> |
66 |
>> Then, is there any other blocker? (apart of the needing of add a news |
67 |
>> item) |
68 |
>> |
69 |
>> Thanks :) |
70 |
>> |
71 |
> |
72 |
> I can't think of anything else. I've filed this bug: |
73 |
> |
74 |
> https://bugs.gentoo.org/show_bug.cgi?id=477664 |
75 |
> |
76 |
|
77 |
userpriv and usersandbox don't work in pypy because os.setgroups isn't |
78 |
implemented there. |
79 |
|
80 |
I had a go at it a while back, but the complete and utter lack of any |
81 |
documentation whatsoever... kinda threw me off. |