1 |
Zac Medico posted on Mon, 28 May 2012 14:34:22 -0700 as excerpted: |
2 |
|
3 |
> In case you aren't familiar with FEATURES=userpriv, here's the |
4 |
> description from the make.conf(5) man page: |
5 |
> |
6 |
> Allow portage to drop root privileges and compile packages as |
7 |
> portage:portage without a sandbox (unless usersandbox is also used). |
8 |
> |
9 |
> The rationale for having the separate "usersandbox" setting, to enable |
10 |
> use of sys-apps/sandbox, is that people who enable userpriv sometimes |
11 |
> prefer to have sandbox disabled in order to slightly improve |
12 |
> performance. However, I would recommend to enable usersandbox by |
13 |
> default, for the purpose of logging sandbox violations. |
14 |
> |
15 |
> Note that ebuilds can set RESTRICT="userpriv" if they require superuser |
16 |
> privileges during any of the src_* phases that userpriv affects. |
17 |
> |
18 |
> I've been using FEATURES="userpriv usersandbox" for years, and I don't |
19 |
> remember experiencing any problems because of it, so I think that it |
20 |
> would be reasonable to have it enabled by default. Objections? |
21 |
|
22 |
I saw the thread on portage-dev so was waiting for the thread here that |
23 |
you mentioned you'd start... |
24 |
|
25 |
Some years ago I had some problem or other with the usersandbox and |
26 |
userpriv combination (AFAIK it would work with just one of the two, but |
27 |
not both), but that was several years ago now, and was almost certainly |
28 |
~arch (and possibly pre-unmask), so yes, I'd say have them both on by |
29 |
default. I've had no problem with it recently. |
30 |
|
31 |
As is traditional for this sort of defaults-change, I'd suggest creating |
32 |
a news item for it, with the usual paragraph explanation and referral to |
33 |
the manpage and/or handbook for more information. |
34 |
|
35 |
If I don't miss my guess, there's likely a number of folks that had |
36 |
either userpriv or userstandbox disabled for some package or other, years |
37 |
ago, who simply forgot about it and never reenabled. I'm usually pretty |
38 |
good about that, and only probably 6-8 months ago realized I had one of |
39 |
the two disabled, and couldn't remember why (probably 2-3 years ago I |
40 |
started putting dated comments in the config when I did stuff like that, |
41 |
so whatever it was, was awhile back...), so it had obviously been |
42 |
disabled for awhile. (I've done at least one and I think two full emerge |
43 |
--emptytree @worlds since then, however, so as I said above, everything |
44 |
that's installed now is fine.) A news item will help remind folks with |
45 |
older installs to check their status as well, which can only be a good |
46 |
thing. =:^) |
47 |
|
48 |
So from this user, +1 (+1000? =:^), news item requested. =:^) |
49 |
|
50 |
-- |
51 |
Duncan - List replies preferred. No HTML msgs. |
52 |
"Every nonfree program has a lord, a master -- |
53 |
and if you use the program, he is your master." Richard Stallman |