-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/29/2012 07:57 AM, hasufell wrote:
> I am against too many defaults. It's documented and people can
> activate it. I'm already annoyed by pre-set stuff like "cups" in
> releases/make.defaults.

In the case of userpriv and usersync, I expect that we can eventually
make them unconditional, so that they'll no longer need to be listed
in FEATURES.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/FSSIACgkQ/ejvha5XGaPTnwCg0QAe1WtZv/wMlMvb5WrxbTk+
jq4AnjTTo77BXYr0d+4F/6P3/447Jk7t
=CuDh
-----END PGP SIGNATURE-----

On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
> On 29 May 2012 12:46, Michael Orlitzky <michael@orlitzky.com> wrote:
>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>> userpriv behavior the default?
>
> rootpriv instead of nouserpriv?

What's the use case for this? Can't we just enable userpriv
unconditionally, so that it doesn't have to be listed in FEATURES? Note
that ebuilds will still be able to use RESTRICT=userpriv if necessary.
--
Thanks,
Zac

On 05/29/12 18:11, Zac Medico wrote:
> On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
>> On 29 May 2012 12:46, Michael Orlitzky <michael@orlitzky.com> wrote:
>>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>>> userpriv behavior the default?
>>
>> rootpriv instead of nouserpriv?
>
> What's the use case for this? Can't we just enable userpriv
> unconditionally, so that it doesn't have to be listed in FEATURES? Note
> that ebuilds will still be able to use RESTRICT=userpriv if necessary.

Would FEATURES=-userpriv still work at the command line? It could be
useful for debugging to keep that working.

On 05/29/2012 04:22 PM, Richard Yao wrote:
> On 05/29/12 18:11, Zac Medico wrote:
>> On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
>>> On 29 May 2012 12:46, Michael Orlitzky <michael@orlitzky.com> wrote:
>>>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>>>> userpriv behavior the default?
>>>
>>> rootpriv instead of nouserpriv?
>>
>> What's the use case for this? Can't we just enable userpriv
>> unconditionally, so that it doesn't have to be listed in FEATURES? Note
>> that ebuilds will still be able to use RESTRICT=userpriv if necessary.
>
> Would FEATURES=-userpriv still work at the command line? It could be
> useful for debugging to keep that working.

Yeah, I guess it would be bad for it to be unconditional, because
permission issues seem to be a really common source of trouble for
people. Even something as seemingly simple as userfetch probably
shouldn't be unconditional, due to issues like the ACLs discussed in bug
#416705 [1].

[1] https://bugs.gentoo.org/show_bug.cgi?id=416705
--
Thanks,
Zac

On 29 May 2012 15:11, Zac Medico <zmedico@gentoo.org> wrote:
> On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
>> On 29 May 2012 12:46, Michael Orlitzky <michael@orlitzky.com> wrote:
>>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>>> userpriv behavior the default?
>>
>> rootpriv instead of nouserpriv?
>
> What's the use case for this? Can't we just enable userpriv
> unconditionally, so that it doesn't have to be listed in FEATURES? Note
> that ebuilds will still be able to use RESTRICT=userpriv if necessary.

Absolutely, this was more in response to the "please no reverse logic"
(which I agree with).

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
> portageortage 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?

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
>> portageortage 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.
--
Thanks,
Zac

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
portageortage 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,
unless there is a very good reason (try) to automate it.

On 07/02/2012 01:36 PM, vivo75@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
>>>> portageortage 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?

> 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
portageortage

I would only trigger something like this once, when upgrading from a
version that doesn't have userpriv enabled by default.
--
Thanks,
Zac

El lun, 02-07-2012 a las 13:45 -0700, Zac Medico escribió:
> On 07/02/2012 01:36 PM, vivo75@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
> >>>> portageortage 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?
>
> > 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
> portageortage
>
> I would only trigger something like this once, when upgrading from a
> version that doesn't have userpriv enabled by default.

This looks reasonable, I think