Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
69 views
Skip to first unread message
Zac Medico
May 28, 2012, 5:40:02 PM5/28/12
to
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
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
Andreas K. Huettel
May 28, 2012, 5:50:02 PM5/28/12
to
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.
> 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?
--
Andreas K. Huettel
Gentoo Linux developer
dilf...@gentoo.org
http://www.akhuettel.de/
Davide Pesavento
May 28, 2012, 6:00:02 PM5/28/12
to
adverse effects, so +1 from me.
Thanks,
Pesa
Michael Weber
May 28, 2012, 7:20:01 PM5/28/12
to
-----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-----
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?
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-----
Duncan
May 28, 2012, 8:00:02 PM5/28/12
to
Zac Medico posted on Mon, 28 May 2012 14:34:22 -0700 as excerpted:
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
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
Maxim Kammerer
May 28, 2012, 9:20:02 PM5/28/12
to
On Tue, May 29, 2012 at 12:34 AM, Zac Medico <zme...@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:
> Note that ebuilds can set RESTRICT="userpriv" if they require superuser
> privileges during any of the src_* phases that userpriv affects.
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.
--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
Rich Freeman
May 28, 2012, 10:00:01 PM5/28/12
to
On Mon, May 28, 2012 at 9:09 PM, Maxim Kammerer <m...@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.
> Ditto, ~2 years with regular full @world rebuild.
>
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
Agostino Sarubbo
May 29, 2012, 4:50:01 AM5/29/12
to
--
Agostino Sarubbo ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D
Zac Medico
May 29, 2012, 5:10:02 AM5/29/12
to
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
Rich Freeman
May 29, 2012, 11:00:02 AM5/29/12
to
On Tue, May 29, 2012 at 10:11 AM, Michał Górny <mgo...@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
>
> Wouldn't that break users who sync using a regular user? And then break
> again, and again every time portage is merged?
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
hasufell
May 29, 2012, 11:10:02 AM5/29/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -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)
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-----
Hash: SHA1
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)
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-----
Rich Freeman
May 29, 2012, 11:30:02 AM5/29/12
to
On Tue, May 29, 2012 at 10:57 AM, hasufell <hasu...@gentoo.org> 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
> 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.
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
hasufell
May 29, 2012, 12:40:02 PM5/29/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
"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
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
31pNy2Q+SKxo4voy5Y1/mt+0lKGrhyDq6npmBY+7n5RlhdKrn8J3VyQ7HQ1jBGiS
nEdSVb6BCHtFeWWWYRo6efooQFsGT+6NOFQgX/xXXgk9Ndzk8LtURGp8oP0oucNt
YWfhDruoUzJXRyIMP9u6SbbDVXOnYVP+WUniNJ855l2Q1jg5lrwE6f6dD7wsbtyp
3PGBEtMqX9nAtzFZ8blUHngyrMP9J/GcJ3OVQkLXla7WBCWLqKlN0pIIiVqe2L5V
45MPQ/Muhyy0JUKLmLJLvx/2c+1I4mCt1lrfZNNN3zhepnjZSLn/uiGZk3JVEQs=
=KNF8
-----END PGP SIGNATURE-----
Jeff Horelick
May 29, 2012, 1:20:01 PM5/29/12
to
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...
Ralph Sennhauser
May 29, 2012, 3:50:02 PM5/29/12
to
On Tue, 29 May 2012 18:27:51 +0200
hasufell <hasu...@gentoo.org> 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
hasufell <hasu...@gentoo.org> wrote:
> Well then let my clarify: I'm against too many pre-set (meaning
> "activated") features/useflags.
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.
Michael Orlitzky
May 29, 2012, 3:50:02 PM5/29/12
to
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".
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".
Mike Gilbert
May 29, 2012, 4:00:02 PM5/29/12
to
On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky <mic...@orlitzky.com> 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
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?
>
entire point of this thread is that Zac wants to change the default to
build as the portage user (FEATURES="userpriv" in make.globals).
William Hubbs
May 29, 2012, 4:10:01 PM5/29/12
to
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.
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?
It is reverse logic and can be very confusing. Just adding "-userpriv"
to your features would do exactly the same thing.
William
Michael Orlitzky
May 29, 2012, 4:30:02 PM5/29/12
to
adding another value to the FEATURES variable, which seems to be
hasufell's objection.
Zac Medico
May 29, 2012, 4:40:01 PM5/29/12
to
the UID and GID of the PORTDIR directory (obtained using the stat function).
> And then break
> again, and again every time portage is merged?
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
Hilco Wijbenga
May 29, 2012, 5:50:01 PM5/29/12
to
On 29 May 2012 12:46, Michael Orlitzky <mic...@orlitzky.com> wrote:
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?
rootpriv instead of nouserpriv?
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?
Zac Medico
May 29, 2012, 6:20:01 PM5/29/12
to
On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
> On 29 May 2012 12:46, Michael Orlitzky <mic...@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
> On 29 May 2012 12:46, Michael Orlitzky <mic...@orlitzky.com> wrote:
>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>> userpriv behavior the default?
>
> rootpriv instead of nouserpriv?
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
Zac Medico
May 29, 2012, 6:20:02 PM5/29/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
> 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.
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+
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
jq4AnjTTo77BXYr0d+4F/6P3/447Jk7t
=CuDh
-----END PGP SIGNATURE-----
Zac Medico
May 29, 2012, 8:50:01 PM5/29/12
to
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
Hilco Wijbenga
May 29, 2012, 9:10:02 PM5/29/12
to
(which I agree with).
Pacho Ramos
Jul 2, 2012, 3:50:02 PM7/2/12
to
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
> 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?
be enabled by default, no? :)
Zac Medico
Jul 2, 2012, 4:10:02 PM7/2/12
to
inside $DISTDIR that are used by live ebuilds, since src_unpack will run
with different privileges when userpriv is enabled.
--
Thanks,
Zac
viv...@gmail.com
Jul 2, 2012, 4:40:02 PM7/2/12
to
unless there is a very good reason (try) to automate it.
Zac Medico
Jul 2, 2012, 4:50:02 PM7/2/12
to
> unless there is a very good reason (try) to automate it.
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
Michał Górny
Jul 3, 2012, 4:10:01 AM7/3/12
to
> > 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
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.
of them actually redefine E*_STORE_DIR to a more sane location. But
that's probably irrelevant.
viv...@gmail.com
Jul 3, 2012, 4:20:02 AM7/3/12
to
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_
> 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.
automate it", even if the chown work flawlessy it become additional
cruft that will be forever with us.
thanks,
Francesco
Andreas K. Huettel
Jul 3, 2012, 10:00:01 AM7/3/12
to
>
> 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...
> 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.
better add a "chmod -R g+w" too...
--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing
Andreas K. Huettel
Jul 3, 2012, 10:00:02 AM7/3/12
to
> > 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
> >
> > 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...
something him/herself either way. I guess we dont have to care for this case.
Pacho Ramos
Jul 21, 2013, 7:00:01 AM7/21/13
to
item)
Thanks :)
Zac Medico
Jul 21, 2013, 2:30:02 PM7/21/13
to
https://bugs.gentoo.org/show_bug.cgi?id=477664
--
Thanks,
Zac
Mike Gilbert
Jul 21, 2013, 2:40:02 PM7/21/13
to
On Sun, Jul 21, 2013 at 2:30 PM, Alex Xu <alex...@yahoo.ca> 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
> 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.
>
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.
0 new messages