1 |
Hi gang. |
2 |
|
3 |
I have looked into the innards of Subterfugue, and hacked together a short |
4 |
C program that captures syscalls from a child. |
5 |
|
6 |
While the program does not do anything with the captured arguments |
7 |
(attached), I do not think there will be a significant overhead associated |
8 |
with path sandboxing at all. |
9 |
|
10 |
The reason for this postulation is that a traced child running "find /" |
11 |
completes at the same time as a non-traced "find /". Only for |
12 |
installations that do extreme amounts of syscalls might we notice an |
13 |
overhead, and I really think "find /" is as syscall-intensive as we'll get |
14 |
during compilation and installation. |
15 |
|
16 |
If anybody else can prove me wrong on that one, now's the time. |
17 |
|
18 |
After adding the path sandboxing code, I will integrate the cut-down |
19 |
fakeroot that chouser (might have) finished, so we have a fairly secure |
20 |
and lean sandbox overall in which build processes can work happily. |
21 |
|
22 |
For those who're not up to date on this subject, the reason why we want a |
23 |
combination of subterfugue's SimplePathSandbox and fakeroot is that |
24 |
1) We don't want ebuilds to write outside of ${S}, /tmp or ${D} |
25 |
2) We really don't want to run the ebuilds as the real root, if we can |
26 |
fake it, |
27 |
hence fakeroot. (Fakeroot lets the ebuild think it runs as root; in |
28 |
practice |
29 |
this infers chown-privileges to a regular user). |
30 |
3) We do not want to use subterfugue since it's too slow. Fakeroot seems |
31 |
to have |
32 |
some features that are overkill for this project, and at any rate, we |
33 |
really |
34 |
only want to do syscall tracing once. (The alternative would be a |
35 |
sandbox |
36 |
process that contained fakeroot that contained the ebuild...) |
37 |
|
38 |
|
39 |
Interested parties, please do some thinking on this. |
40 |
|
41 |
Oh, I will be away until Thursday, so you have plenty of time ;p |
42 |
|
43 |
|
44 |
Kind regards, |
45 |
|
46 |
Karl T |