| 1 |
On Thu, 11 Jan 2007 09:38:29 +0900 Georgi Georgiev <chutz@×××.net> |
| 2 |
wrote: |
| 3 |
| Quoting Ciaran McCreesh <ciaranm@×××××××.org>: |
| 4 |
| > On Thu, 11 Jan 2007 09:07:54 +0900 Georgi Georgiev <chutz@×××.net> |
| 5 |
| > wrote: |
| 6 |
| > | Further, by adopting ACCEPT_RESTRICT, it would be possible to be |
| 7 |
| > | able to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch |
| 8 |
| > | anything outside the sandbox. |
| 9 |
| > | ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated |
| 10 |
| > | privileges. |
| 11 |
| > |
| 12 |
| > Which gains what, exactly? These are not things about which the end |
| 13 |
| > user should be concerned. |
| 14 |
| |
| 15 |
| A user shouldn't be concerned if an ebuild wants to leave the |
| 16 |
| sandbox when not supposed to? |
| 17 |
|
| 18 |
Correct. *Developers* should be concerned about whether their package |
| 19 |
installs and uninstalls correctly. If an ebuild is leaving the sandbox, |
| 20 |
it's doing so because it's necessary (at least at present -- this |
| 21 |
proposal will make it more like "because the developer couldn't be |
| 22 |
bothered to fix something"). |
| 23 |
|
| 24 |
Remember that packages can still do bad stuff to the filesystem even |
| 25 |
when sandbox is turned on. The point of sandbox is to be a safety |
| 26 |
feature, not a security measure. |
| 27 |
|
| 28 |
-- |
| 29 |
Ciaran McCreesh |
| 30 |
Mail : ciaranm at ciaranm.org |
| 31 |
Web : http://ciaranm.org/ |
| 32 |
Paludis, the secure package manager : http://paludis.pioto.org/ |
Archives