| 1 |
On Thu, 2007-01-11 at 09:07 +0900, Georgi Georgiev wrote: |
| 2 |
> Further, by adopting ACCEPT_RESTRICT, it would be possible to be able to say: |
| 3 |
> ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch anything outside |
| 4 |
> the sandbox. |
| 5 |
|
| 6 |
|
| 7 |
> ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated privileges. |
| 8 |
|
| 9 |
|
| 10 |
Exactly. |
| 11 |
|
| 12 |
Currently, it's read like this: |
| 13 |
|
| 14 |
FEATURES, RESTRICT |
| 15 |
|
| 16 |
What we're proposing is this: |
| 17 |
|
| 18 |
FEATURES, RESTRICT, ACCEPT_RESTRICT |
| 19 |
|
| 20 |
Imagine you have userpriv in FEATURES. If an ebuild has |
| 21 |
RESTRICT=userpriv, it *WILL* disable userpriv, no matter what the user |
| 22 |
does. Adding ACCEPT_RESTRICT allows the user to not list userpriv (or |
| 23 |
-userpriv if userpriv is on by default) and the ebuild WILL NOT RUN if |
| 24 |
it requires userpriv be disabled. |
| 25 |
|
| 26 |
-- |
| 27 |
Chris Gianelloni |
| 28 |
Release Engineering Strategic Lead |
| 29 |
Alpha/AMD64/x86 Architecture Teams |
| 30 |
Games Developer/Council Member/Foundation Trustee |
| 31 |
Gentoo Foundation |
Archives