On Thu, Mar 8, 2018 at 7:06 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu <hero...@gentoo.org> wrote:
>> Rich Freeman <ri...@gentoo.org> writes:
>>
>>> If you have util-linux installed then try running (as any user - you
>>> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U
>>> -r /bin/bash
>>>
>>> Congrats.  You are now root in a container.  You're in the same root
>>> filesystem as always.  You'll note that you can't actually see
>>> anything that you couldn't see before.  If you run ps -ea you'll see
>>> that you're the only process running on the system.  Devices like
>>> /dev/sda aren't actually accessible.  A lot of container managers
>>> would mount a new /dev and just hide most of that stuff.  You can
>>> probably imagine how something like this could be useful for isolating
>>> processes.
>>
>> Just a side node, this seems to be the ultimate sandbox we (Gentoo and
>> portage) are after.  With this, we might even be able to have portage
>> full functional: a build is completely determined and only determined by
>> the dependencies and USE flags.
>>
>
> I'm not sure how well this would perform, but I had given this a bit
> of thought a few years ago.  There are two obvious ways to go about
> this: the sandbox or containers.
>

It may be possible to use fanotify(7) (but this would only catch disk
access). There is an extension to fanotify created as someone's thesis
(http://lkml.iu.edu/hypermail/linux/kernel/1703.1/05249.html) that
allows recursive watches. One of the features of fanotify is that it
is possible to deny the events generated. The fanotify API may
simplify the application of the generated rules. It was designed to be
fast, and most processing is done in the kernel when calls are made.

Sadly interest in the patches seems to have waned. The functionality
is not exactly duplicated in containers, but they do make it easier to
find changes.

Reply via email to