On 21/07/13 02:25 PM, Zac Medico wrote:
> On 07/21/2013 03:53 AM, Pacho Ramos wrote:
>> El mar, 03-07-2012 a las 10:02 +0200, Michał Górny escribió:
>>> On Mon, 02 Jul 2012 13:45:26 -0700
>>> Zac Medico <zmed...@gentoo.org> wrote:
>>>
>>>> On 07/02/2012 01:36 PM, viv...@gmail.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?
>>>
>>> I think this deserves a news item anyway.
>>>
>>>>> 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
>>>
>>> find "$DISTDIR" -maxdepth 1 -type d -uid 0 -exec \
>>> 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.
>>>
>>> This will work only for users who actually keep those in DISTDIR. Some
>>> of them actually redefine E*_STORE_DIR to a more sane location. But
>>> that's probably irrelevant.
>>>
>>
>> Then, is there any other blocker? (apart of the needing of add a news
>> item)
>>
>> Thanks :)
>>
>
> I can't think of anything else. I've filed this bug:
>
> https://bugs.gentoo.org/show_bug.cgi?id=477664
> userpriv and usersandbox don't work in pypy because os.setgroups isn't implemented there. I had a go at it a while back, but the complete and utter lack of any documentation whatsoever... kinda threw me off.
signature.asc
Description: OpenPGP digital signature
