On Tue, 29 May 2012 02:05:08 -0700
Zac Medico <email@example.com> wrote:
> On 05/29/2012 01:43 AM, Agostino Sarubbo wrote:
> > On Monday 28 May 2012 14:34:22 Zac Medico wrote:
> >> Hi,
> >> In case you aren't familiar with FEATURES=userpriv, here's the
> >> description from the make.conf(5) man page:
> >> Allow portage to drop root privileges and compile packages as
> >> portage:portage without a sandbox (unless usersandbox is also
> >> used).
> >> The rationale for having the separate "usersandbox" setting, to
> >> enable use of sys-apps/sandbox, is that people who enable userpriv
> >> sometimes prefer to have sandbox disabled in order to slightly
> >> improve performance. However, I would recommend to enable
> >> usersandbox by default, for the purpose of logging sandbox
> >> violations.
> >> Note that ebuilds can set RESTRICT="userpriv" if they require
> >> superuser privileges during any of the src_* phases that userpriv
> >> affects.
> >> I've been using FEATURES="userpriv usersandbox" for years, and I
> >> don't remember experiencing any problems because of it, so I think
> >> that it would be reasonable to have it enabled by default.
> >> Objections?
> > I'm using usersync since a long time, how about add it too?
> Yeah, I think that would be a good default too. I guess the portage
> ebuild can do a recursive adjustment of $PORTDIR permissions in
> pkg_postinst, in order to solve bug #277970 .
Wouldn't that break users who sync using a regular user? And then break
again, and again every time portage is merged?