[gentoo-dev] Braindump wrt fakeroot and path sandboxing

[gentoo-dev] Braindump wrt fakeroot and path sandboxing

[Karl Trygve Kalleberg]

Hi gang.

I have looked into the innards of Subterfugue, and hacked together a short
C program that captures syscalls from a child. 

While the program does not do anything with the captured arguments
(attached), I do not think there will be a significant overhead associated
with path sandboxing at all.

The reason for this postulation is that a traced child running "find /"
completes at the same time as a non-traced "find /". Only for
installations that do extreme amounts of syscalls might we notice an
overhead, and I really think "find /" is as syscall-intensive as we'll get
during compilation and installation.

If anybody else can prove me wrong on that one, now's the time.

After adding the path sandboxing code, I will integrate the cut-down
fakeroot that chouser (might have) finished, so we have a fairly secure
and lean sandbox overall in which build processes can work happily.

For those who're not up to date on this subject, the reason why we want a
combination of subterfugue's SimplePathSandbox and fakeroot is that
1) We don't want ebuilds to write outside of ${S}, /tmp or ${D}
2) We really don't want to run the ebuilds as the real root, if we can
fake it,
   hence fakeroot. (Fakeroot lets the ebuild think it runs as root; in
practice
   this infers chown-privileges to a regular user).
3) We do not want to use subterfugue since it's too slow. Fakeroot seems
to have
   some features that are overkill for this project, and at any rate, we
really
   only want to do syscall tracing once. (The alternative would be a
sandbox
   process that contained fakeroot that contained the ebuild...)


Interested parties, please do some thinking on this.

Oh, I will be away until Thursday, so you have plenty of time ;p


Kind regards,

Karl T

Re: [gentoo-dev] Braindump wrt fakeroot and path sandboxing

[Chad Huneycutt]

Karl Trygve Kalleberg wrote:

> For those who're not up to date on this subject, the reason why we want a
> combination of subterfugue's SimplePathSandbox and fakeroot is that
> 1) We don't want ebuilds to write outside of ${S}, /tmp or ${D}
> 2) We really don't want to run the ebuilds as the real root, if we can
> fake it,
>    hence fakeroot. (Fakeroot lets the ebuild think it runs as root; in
> practice
>    this infers chown-privileges to a regular user).
> 3) We do not want to use subterfugue since it's too slow. Fakeroot seems
> to have
>    some features that are overkill for this project, and at any rate, we
> really
>    only want to do syscall tracing once. (The alternative would be a
> sandbox
>    process that contained fakeroot that contained the ebuild...)

I am sure I have heard the argument, but I can't remember it.  Is there 
a reason other than (2) that we can't just do a chroot to the image 
directory?

-- 
Chad Huneycutt
Ph.D. Student
http://www.cc.gatech.edu/~chadh

Re: [gentoo-dev] Braindump wrt fakeroot and path sandboxing

[Aron Griffis]

Chad Huneycutt wrote:	[Fri Nov 02 2001, 11:45:22AM EST]
> I am sure I have heard the argument, but I can't remember it.  Is there 
> a reason other than (2) that we can't just do a chroot to the image 
> directory?

Because you'll get lots of errors like 

    bash: make: No such file or directory

In other words, you would need to provide the entire environment for the
package in the image directory.  Make, install, and whatever else the
given Makefile is expecting.

Aron