| 1 |
Quoting Ciaran McCreesh <ciaranm@×××××××.org>: |
| 2 |
|
| 3 |
> On Fri, 12 Jan 2007 06:38:23 +0900 Georgi Georgiev <chutz@×××.net> |
| 4 |
> wrote: |
| 5 |
> | I agree that if an ebuild wants to misbehave it can and there is no |
| 6 |
> | stopping it. However, code that is executed in pkg_* is generally |
| 7 |
> | restricted to code written by the person who is involved in |
| 8 |
> | maintaining the ebuild. It is easy to read that code and see what it |
| 9 |
> | does. In contrast, the stuff that is run with lowered privileges is |
| 10 |
> | usually coded upstream. I'd like to have that run with lowered |
| 11 |
> | privileges, no matter what. |
| 12 |
> |
| 13 |
> So you trust upstream to install arbitrary content on your computer, |
| 14 |
> some of which may not be removed even when you uninstall the package, |
| 15 |
> but you don't trust the package to compile with elevated privs, even |
| 16 |
> when a Gentoo developer has carefully checked why userpriv is required? |
| 17 |
|
| 18 |
Why would it not be removed? Upstream installs in the sandbox, the |
| 19 |
contents of the sandbox are recorded in the package database and with |
| 20 |
collision-protect it will not override random stuff on my computer. If |
| 21 |
I uninstall the package without ever touching it, everything will be |
| 22 |
removed. I do exclude the pkg_* phases from the above, but we already |
| 23 |
agreed that nothing from upstream executes there. |
| 24 |
|
| 25 |
Still, your point makes sense. But I hope that you will agree that as |
| 26 |
long as FEATURES=userpriv exists it should be enforced. If it can be |
| 27 |
circumvented the FEATURE may as well be removed and the whole problem |
| 28 |
dealt with. |
| 29 |
|
| 30 |
|
| 31 |
---------------------------------------------------------------- |
| 32 |
This message was sent using IMP, the Internet Messaging Program. |
| 33 |
|
| 34 |
|
| 35 |
-- |
| 36 |
gentoo-dev@g.o mailing list |
Archives