FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-28-2012, 11:17 PM
Michael Weber
 
Default 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-----
 
Old 05-28-2012, 11:56 PM
Duncan
 
Default RFC: Enable FEATURES="userpriv usersandbox" by default?

Zac Medico posted on Mon, 28 May 2012 14:34:22 -0700 as excerpted:

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

I saw the thread on portage-dev so was waiting for the thread here that
you mentioned you'd start...

Some years ago I had some problem or other with the usersandbox and
userpriv combination (AFAIK it would work with just one of the two, but
not both), but that was several years ago now, and was almost certainly
~arch (and possibly pre-unmask), so yes, I'd say have them both on by
default. I've had no problem with it recently.

As is traditional for this sort of defaults-change, I'd suggest creating
a news item for it, with the usual paragraph explanation and referral to
the manpage and/or handbook for more information.

If I don't miss my guess, there's likely a number of folks that had
either userpriv or userstandbox disabled for some package or other, years
ago, who simply forgot about it and never reenabled. I'm usually pretty
good about that, and only probably 6-8 months ago realized I had one of
the two disabled, and couldn't remember why (probably 2-3 years ago I
started putting dated comments in the config when I did stuff like that,
so whatever it was, was awhile back...), so it had obviously been
disabled for awhile. (I've done at least one and I think two full emerge
--emptytree @worlds since then, however, so as I said above, everything
that's installed now is fine.) A news item will help remind folks with
older installs to check their status as well, which can only be a good
thing. =:^)

So from this user, +1 (+1000? =:^), news item requested. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 05-29-2012, 01:09 AM
Maxim Kammerer
 
Default RFC: Enable FEATURES="userpriv usersandbox" by default?

On Tue, May 29, 2012 at 12:34 AM, Zac Medico <zmedico@gentoo.org> 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-9999 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
 
Old 05-29-2012, 01:58 AM
Rich Freeman
 
Default RFC: Enable FEATURES="userpriv usersandbox" by default?

On Mon, May 28, 2012 at 9:09 PM, Maxim Kammerer <mk@dee.su> 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
 
Old 05-29-2012, 08:43 AM
Agostino Sarubbo
 
Default 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
> 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?

I'm using usersync since a long time, how about add it too?
--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D
 
Old 05-29-2012, 08:58 AM
Richard Yao
 
Default 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.
 
Old 05-29-2012, 09:05 AM
Zac Medico
 
Default 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
>> 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?
>
> 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
 
Old 05-29-2012, 02:11 PM
Michał Górny
 
Default RFC: Enable FEATURES="userpriv usersandbox" by default?

On Tue, 29 May 2012 02:05:08 -0700
Zac Medico <zmedico@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
> >> 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?
> >
> > 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
 
Old 05-29-2012, 02:50 PM
Rich Freeman
 
Default RFC: Enable FEATURES="userpriv usersandbox" by default?

On Tue, May 29, 2012 at 10:11 AM, Michał Górny <mgorny@gentoo.org> 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
 
Old 05-29-2012, 02:57 PM
hasufell
 
Default 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 <mgorny@gentoo.org>
> 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+cZvFF3SvqhORMeXlgccbqU2kBy2Bwcq2GwKKmYIdKwnA2J0 KKwqLkHraD
8pkTzUsvqxnQVqFGfCvFyJe3uwiJKQoTIAGugf3n9irvczuZTQ 9MDWoZkGKiaNI=
=eo74
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 08:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org