On Tue, 29 May 2012 02:05:08 -0700 Zac Medico <zmed...@gentoo.org> 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 [1]. Wouldn't that break users who sync using a regular user? And then break again, and again every time portage is merged? -- Best regards, Michał Górny
signature.asc
Description: PGP signature
