Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds

[Rich Freeman]

On Tue, Jul 31, 2012 at 7:57 PM, vivo75@×××××.com <vivo75@×××××.com> wrote:
> Il 31/07/2012 21:27, Michał Górny ha scritto:
>> I'd be more afraid about resources, and whether the kernel will be
>> actually able to handle bazillion bind mounts. And if, whether it won't
>> actually cause more overhead than copying the whole system to some kind
>> of tmpfs.
>
> If testing show that bind mounts are too heavy we could resort to LD_PRELOAD
> a library that filter the acces to the disk,
> or to rework sandbox to also hide w/o errors some files,
> with an appropriate database (sys-apps/mlocate come to mind) every access
> will have negligible additional cost compared to that of rotational disks.

So, while I suspect that bind mount overhead won't actually be that
bad, I'm also thinking that extending the role of sandbox as has
already been suggested might be the simpler solution (and it works on
other kernels as well).  I'd still like a run-time solution some day,
but that would probably require SELinux and seems like a much more
ambitious project, and we'll probably get quite a bit of QA value out
of a sandbox solution.

I think the right solution is to not use external utilities unless
they can be linked in - at least not for anything running in sandbox.
We're talking about at VERY high volume of file opens most likely and
we can't be spawning processes every time that happens, let alone
running bash scripts or whatever.

So, here is my design concept (which had a little help from my LUG - PLUG):

1.  At the start of the build, portage generates a list of files that
are legitimate dependencies - anything in DEPEND or @system.  This can
be done by parsing the /var/pkg/db files (I assume portage has some
internal API for this already).

2.  Portage or a helper program (whatever is fastest) calls stat on
each file to obtain the device and inode IDs.  Maybe long-term we
might consider caching these (but I'm not sure how stable they are).

3.  The list of valid device/inode IDs are passed to sandbox somehow
(maybe in a file).  Sandbox creates a data structure in memory
containing them for rapid access (btree or such).

4.  When sandbox intercepts a file open request, it checks the file
inode against the list and allows/denies accordingly.

That said, after doing a quick pass at the sandbox source it seems
like it already is designed to restrict read access, but it uses
canonical filenames to do so. I'm not sure if those are going to be
reliable, especially if a filesystem contains bind mounts.  Since it
is already checking a read list if we thought that mechnism would be
robust and fast, we could just remove SANDBOX_READ="/" from
/etc/sandbox.d/00default and then load in whatever we want afterwards.
 I need to spend more time groking the current source.  I'd think that
using inode numbers as a key would be faster than determining a
canonical file name on every file access, but if sandbox is already
doing the latter then obviously it isn't that much overhead.

The other thing I'm not sure about here are symlinks.  If a symlink is
contained in a dependency, but the linked file is not, can that file
be used by a package?  I suppose the reverse is also a concern - if a
file is accessed through a symlink that isn't part of a dependency,
but the file it is pointing to is, is that a problem?  I'm wondering
if there is any eselect logic that could cause problems here.  When
calling stat we can choose whether to dereference symlinks.