Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Sun, Jul 21, 2013 at 2:30 PM, Alex Xu wrote: > 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. > I don't think we need to tailor the default configuration to meet the limitations imposed by an experimental python interpreter. If it can be worked around, great, but it should not stop us from enabling userpriv and usersandbox by default.
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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 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
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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 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
--
Thanks,
Zac
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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 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 :)
Re: Re: Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
> > 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. > > If you run ebuild as user (belonging to group portage), that won't help... > better add a "chmod -R g+w" too... Scratch that. It would not have worked before either, so the user has to do something him/herself either way. I guess we dont have to care for this case. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
> > 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. If you run ebuild as user (belonging to group portage), that won't help... better add a "chmod -R g+w" too... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
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, 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? 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. ba, 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
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Mon, 02 Jul 2012 13:45:26 -0700
Zac Medico 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.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
El lun, 02-07-2012 a las 13:45 -0700, Zac Medico escribió: > 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? > > > 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. This looks reasonable, I think signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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? > 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. -- Thanks, Zac
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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, unless there is a very good reason (try) to automate it.
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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. -- Thanks, Zac
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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? :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 29 May 2012 15:11, Zac Medico wrote: > On 05/29/2012 02:47 PM, Hilco Wijbenga wrote: >> On 29 May 2012 12:46, Michael Orlitzky 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).
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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 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
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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 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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 05/29/2012 02:47 PM, Hilco Wijbenga wrote: > On 29 May 2012 12:46, Michael Orlitzky 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
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
-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-
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 29 May 2012 12:46, Michael Orlitzky wrote: > How about introducing e.g. FEATURES="nouserpriv", and make the current > userpriv behavior the default? rootpriv instead of nouserpriv? > The migration might be a bit more confusing, but it allows portage to > gradually adopt better stuff without having FEATURES="everything under > the sun".
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 05/29/2012 07:11 AM, Michał Górny wrote: > On Tue, 29 May 2012 02:05:08 -0700 > Zac Medico wrote: > >> On 05/29/2012 01:43 AM, Agostino Sarubbo wrote: >>> 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? No, because the "usersync" feature causes the rsync process to inherit the UID and GID of the PORTDIR directory (obtained using the stat function). > And then break > again, and again every time portage is merged? No, I would not want to trigger an relatively expensive operation like this more that once. So, it would only be triggered in pkg_postinst if the replaced version of portage did not have usersync enabled by default. -- Thanks, Zac
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 05/29/12 15:58, Mike Gilbert wrote: > On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky > wrote: >> How about introducing e.g. FEATURES="nouserpriv", and make the current >> userpriv behavior the default? >> > > Portage currently defaults to running the build process as root. The > entire point of this thread is that Zac wants to change the default to > build as the portage user (FEATURES="userpriv" in make.globals). > Right, I was just offering a way to change the default behavior without adding another value to the FEATURES variable, which seems to be hasufell's objection.
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, May 29, 2012 at 03:46:39PM -0400, Michael Orlitzky wrote: > How about introducing e.g. FEATURES="nouserpriv", and make the current > userpriv behavior the default? No. Please stay away from things like this. It is reverse logic and can be very confusing. Just adding "-userpriv" to your features would do exactly the same thing. William pgpDBWymIk6cT.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky wrote: > How about introducing e.g. FEATURES="nouserpriv", and make the current > userpriv behavior the default? > Portage currently defaults to running the build process as root. The entire point of this thread is that Zac wants to change the default to build as the portage user (FEATURES="userpriv" in make.globals).
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
How about introducing e.g. FEATURES="nouserpriv", and make the current userpriv behavior the default? The migration might be a bit more confusing, but it allows portage to gradually adopt better stuff without having FEATURES="everything under the sun".
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, 29 May 2012 18:27:51 +0200 hasufell wrote: > Well then let my clarify: I'm against too many pre-set (meaning > "activated") features/useflags. Think of it as nouserpriv feature. ;) Either way, to disable userpriv is kind of working against QA as a package really should be build-able as non root user but then. Have userpriv and usersandbox enabled since it's became available, no issues to report. signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 29 May 2012 12:27, hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/29/2012 05:23 PM, Rich Freeman wrote: >> On Tue, May 29, 2012 at 10: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. >> >> While universal agreement is a bit much to hope for, I just wanted >> to point out that fewer defaults is really just an illusion. >> >> There is ALWAYS a default, anytime you have an option. The >> default might be one thing, or it might be another, but there is >> ALWAYS a default. My thinking is that our defaults should >> generally reflect the most mainstream or least-surprising behavior, >> especially where there are upstream projects. in the case of >> portage, we are the upstream, so we should do whatever is most >> useful and least obnoxious to our users. >> >> If you're running something other than a generic desktop/server, >> there will always be a need to tweak things. >> >> Rich >> > > Well then let my clarify: I'm against too many pre-set (meaning > "activated") features/useflags. > > That's probably a seperate discussion, but I myself would expect the > _default_ profile/config to have almost nothing activated. No > useflags, no features etc. > > That may imply that this default is "broken", but it takes more time > to do reverse-configuration while looking for things that someone > considered "sane" and has set for your "convenience". > > I discovered this the first time I set up a blank chroot and got a > load of stuff pulled in by some trivial emerges. Some set by already > mentioned releases/make.defaults and similar, some set by ebuilds etc. > > What you do with other profiles is a completely different topic, > because I'm not forced to use them. > > means: I don't like the fact that I have to set > FEATURES="-foobar" > or > USE="-foobar" > > That should almost never be the case (unless I set some globally and > unset some locally or use desktop-profiles etc). > > am I offtopic already? Hope you got the point though. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPxPkHAAoJEFpvPKfnPDWzejcH/3g1VGmSRHufoQMHUpi6X1x3 > 31pNy2Q+SKxo4voy5Y1/mt+0lKGrhyDq6npmBY+7n5RlhdKrn8J3VyQ7HQ1jBGiS > nEdSVb6BCHtFeWWWYRo6efooQFsGT+6NOFQgX/xXXgk9Ndzk8LtURGp8oP0oucNt > YWfhDruoUzJXRyIMP9u6SbbDVXOnYVP+WUniNJ855l2Q1jg5lrwE6f6dD7wsbtyp > 3PGBEtMqX9nAtzFZ8blUHngyrMP9J/GcJ3OVQkLXla7WBCWLqKlN0pIIiVqe2L5V > 45MPQ/Muhyy0JUKLmLJLvx/2c+1I4mCt1lrfZNNN3zhepnjZSLn/uiGZk3JVEQs= > =KNF8 > -END PGP SIGNATURE- > I disagree with this. I think Gentoo should be about SANE defaults. If you want a minimal system, you can turn off all the USE flags and/or FEATURES and/or use the standard (not desktop/) profile. SANE defaults like FEATURES="userpriv usersandbox" are optimal for probably 90% of users and if you're not one of those 90%, there'll be a news item, just turn them off...
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2012 05:23 PM, Rich Freeman wrote: > On Tue, May 29, 2012 at 10: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. > > While universal agreement is a bit much to hope for, I just wanted > to point out that fewer defaults is really just an illusion. > > There is ALWAYS a default, anytime you have an option. The > default might be one thing, or it might be another, but there is > ALWAYS a default. My thinking is that our defaults should > generally reflect the most mainstream or least-surprising behavior, > especially where there are upstream projects. in the case of > portage, we are the upstream, so we should do whatever is most > useful and least obnoxious to our users. > > If you're running something other than a generic desktop/server, > there will always be a need to tweak things. > > Rich > Well then let my clarify: I'm against too many pre-set (meaning "activated") features/useflags. That's probably a seperate discussion, but I myself would expect the _default_ profile/config to have almost nothing activated. No useflags, no features etc. That may imply that this default is "broken", but it takes more time to do reverse-configuration while looking for things that someone considered "sane" and has set for your "convenience". I discovered this the first time I set up a blank chroot and got a load of stuff pulled in by some trivial emerges. Some set by already mentioned releases/make.defaults and similar, some set by ebuilds etc. What you do with other profiles is a completely different topic, because I'm not forced to use them. means: I don't like the fact that I have to set FEATURES="-foobar" or USE="-foobar" That should almost never be the case (unless I set some globally and unset some locally or use desktop-profiles etc). am I offtopic already? Hope you got the point though. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPxPkHAAoJEFpvPKfnPDWzejcH/3g1VGmSRHufoQMHUpi6X1x3 31pNy2Q+SKxo4voy5Y1/mt+0lKGrhyDq6npmBY+7n5RlhdKrn8J3VyQ7HQ1jBGiS nEdSVb6BCHtFeWWWYRo6efooQFsGT+6NOFQgX/xXXgk9Ndzk8LtURGp8oP0oucNt YWfhDruoUzJXRyIMP9u6SbbDVXOnYVP+WUniNJ855l2Q1jg5lrwE6f6dD7wsbtyp 3PGBEtMqX9nAtzFZ8blUHngyrMP9J/GcJ3OVQkLXla7WBCWLqKlN0pIIiVqe2L5V 45MPQ/Muhyy0JUKLmLJLvx/2c+1I4mCt1lrfZNNN3zhepnjZSLn/uiGZk3JVEQs= =KNF8 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, May 29, 2012 at 10: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. While universal agreement is a bit much to hope for, I just wanted to point out that fewer defaults is really just an illusion. There is ALWAYS a default, anytime you have an option. The default might be one thing, or it might be another, but there is ALWAYS a default. My thinking is that our defaults should generally reflect the most mainstream or least-surprising behavior, especially where there are upstream projects. in the case of portage, we are the upstream, so we should do whatever is most useful and least obnoxious to our users. If you're running something other than a generic desktop/server, there will always be a need to tweak things. Rich
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2012 04:50 PM, Rich Freeman wrote: > On Tue, May 29, 2012 at 10:11 AM, Michał Górny > wrote: >> >> Wouldn't that break users who sync using a regular user? And then >> break again, and again every time portage is merged? > > Yup, unless that regular user is the same one used for userpriv > (if I'm correctly understanding the problem that you're pointing > at). I don't see this as a show-stopper - just a reason to have a > news item. Those not using userpriv can always disable it and run > as root as they are already doing. Those who are using a regular > user to sync could ensure that their make.conf uses the same user > for userpriv. > > Rich > - -1 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. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPxOPzAAoJEFpvPKfnPDWz9d8H/A0AQr57nDv/0n0+jN8bxdxc nPQyBN9faSuh8IYztQmFe1Xpn/JFx9LoqRGQrvncMmzjmPkM1iaoXUpuo/qw5Fys ar9pN84yZoAJuzgMdLzLs0U/6lqkvLzO+x1Y5DkNU2F+h3Bx9sAk+4vCUjEYg/pC UdXkeRONaB62p/D2T2ucP6IuG6qBI/raW7vvDvkiDGzVbNnDBe4hGESh3Fb4Gd/Y x/P/QJ+cZvFF3SvqhORMeXlgccbqU2kBy2Bwcq2GwKKmYIdKwnA2J0KKwqLkHraD 8pkTzUsvqxnQVqFGfCvFyJe3uwiJKQoTIAGugf3n9irvczuZTQ9MDWoZkGKiaNI= =eo74 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, May 29, 2012 at 10:11 AM, Michał Górny wrote: > > Wouldn't that break users who sync using a regular user? And then break > again, and again every time portage is merged? Yup, unless that regular user is the same one used for userpriv (if I'm correctly understanding the problem that you're pointing at). I don't see this as a show-stopper - just a reason to have a news item. Those not using userpriv can always disable it and run as root as they are already doing. Those who are using a regular user to sync could ensure that their make.conf uses the same user for userpriv. Rich
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, 29 May 2012 02:05:08 -0700 Zac Medico 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
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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]. For userpriv, it will have to do a similar recursive adjustment of permissions for directories inside $DISTDIR (such as git-src and svn-src), since userpriv causes src_unpack to run with lower privileges. [1] https://bugs.gentoo.org/show_bug.cgi?id=277970 -- Thanks, Zac
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 05/29/12 04:43, Agostino Sarubbo wrote: > I'm using usersync since a long time, how about add it too? This is also a good idea. I second it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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? -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Mon, May 28, 2012 at 9:09 PM, Maxim Kammerer wrote: > Ditto, ~2 years with regular full @world rebuild. > Yup, been years since the last time I even saw a bug for this. Probably wouldn't hurt to announce in news if it will impact existing users. I doubt anybody would actually remove the portage user, but never hurts just to make people aware... Rich
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, May 29, 2012 at 12:34 AM, Zac Medico wrote: > Note that ebuilds can set RESTRICT="userpriv" if they require superuser > privileges during any of the src_* phases that userpriv affects. Current list of packages in portage using userpriv restriction: app-laptop/tp_smapi dev-db/firebird games-board/gnuchess-book games-fps/quakeforge games-rpg/wastesedge gnome-extra/gnome-lirc-properties mail-filter/qmail-scanner (vpopmail) media-gfx/gtkimageview media-gfx/imagemagick (when USE=perl) net-dialup/ltmodem net-libs/courier-authlib (vpopmail) net-mail/courier-imap (vpopmail) net-mail/qmailadmin (vpopmail) net-mail/vpopmail (old stable) net-misc/icaclient sys-fs/udev (when USE=test for udev- only) It could also be that anything vpopmail-related doesn't need RESTRICT=userpriv anymore. > 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. Ditto, ~2 years with regular full @world rebuild. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/28/2012 11:34 PM, Zac Medico wrote: > 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? It was/is default on default/linux/amd64/10.0/developer (the one we all should use ?) +1 - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/EB5EACgkQknrdDGLu8JBVyAD/a/Szj+swzSIkAgZv2bGzezIQ M/2+tZUUk+ZE6HlkDrsA/RufmJGlAEa9MJtImaTo/h9svEG/BhioQNvo49nT2ssi =IRjv -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Mon, May 28, 2012 at 11:34 PM, 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? > -- > Thanks, > Zac > I've been using both FEATURES for a few years too, seemingly without adverse effects, so +1 from me. Thanks, Pesa
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
Am Montag 28 Mai 2012, 23:34:22 schrieb Zac Medico: > 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? No objections. Excellent idea. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
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? -- Thanks, Zac
