Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Cc: zmedico@g.o
Subject: Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
Date: Sun, 21 Jul 2013 10:53:20
Message-Id: 1374403990.23081.54.camel@localhost
In Reply to: Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default? by "Michał Górny"
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 :)

Replies