Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

Il 02/07/2012 22:45, Zac Medico ha scritto:
> On 07/02/2012 01:36 PM, vivo75@×××××.com wrote:
>> Il 02/07/2012 22:01, Zac Medico ha scritto:
>>> On 07/02/2012 12:48 PM, Pacho Ramos wrote:
>>>> El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
>>>>> 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?
>>>> Looks like non important problems arised and, then, these could probably
>>>> be enabled by default, no? :)
>>> I'm not sure about the best way to handle migration for directories
>>> inside $DISTDIR that are used by live ebuilds, since src_unpack will run
>>> with different privileges when userpriv is enabled.
>> tell the user to chown/remove the files/directories if and when needed,
> How should we tell them? Elog message, news item, or both?
both seem reasonable, additionally emerge will and should fail when it 
meet a incorrect owned directory, the most sensitive place where to 
output the message is exactly there if possible.
"Failed to update $DIR, check permission and/or correctness, as a last 
resort remove it" something like this, written by someone who speak english.
>> unless there is a very good reason (try) to automate it.
> I guess something like this might work in pkg_postinst of the portage
> ebuild:
>
>    find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
> portage:portage
>
> I would only trigger something like this once, when upgrading from a
> version that doesn't have userpriv enabled by default.
baaaaa, I've totally inverted the logic, it was meant "do _not_  
automate it", even if the chown work flawlessy it become additional 
cruft that will be forever with us.

thanks,
Francesco