1 |
>>>>> On Thu, 13 Sep 2012, Brian Harring wrote: |
2 |
|
3 |
> Note there is a few vars we need to exempt; that list is currently |
4 |
> SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule. |
5 |
> |
6 |
> For SANDBOX_*, while that's a PM internal, that's a bit of a grey |
7 |
> zone; regardless, we can actually address that via extending the |
8 |
> sandbox functions a bit: |
9 |
> |
10 |
> addwrite [-r|--remove] pathway # for example, to do a removal. |
11 |
|
12 |
As already discussed on IRC, a -r option may have undesired effects. |
13 |
For example: |
14 |
|
15 |
addwrite /foo/bar |
16 |
# some commands writing to /foo/bar here |
17 |
addwrite -r /foo/bar # try to restore previous state |
18 |
|
19 |
Now if /foo/bar was in SANDBOX_WRITE before, it's now removed from it. |
20 |
|
21 |
Maybe it's better to add a --{save,restore} option pair: |
22 |
|
23 |
addwrite --save /foo/bar |
24 |
# some commands writing to /foo/bar here |
25 |
addwrite --restore # restore last saved state |
26 |
|
27 |
or --{push,pop} to allow for nested calls, but maybe that would be |
28 |
overkill. |
29 |
|
30 |
> For instances where the sandbox needs to be turned off for a command- |
31 |
> we do the same thing we did w/ nonfatal; |
32 |
> |
33 |
> sandboxless <the command and args> |
34 |
|
35 |
To start the bikeshedding: For some reason I associate "less (the |
36 |
pager) in a sandbox" with this. ;-) Maybe "nosandbox" or "sandboxoff"? |
37 |
|
38 |
Ulrich |