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