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. Either way you first go through the declared dependencies (and @system under our current policies) and obtain a list of all files installed by these packages. Then you either bind mount those files into a container, or add them to the sandbox configuration as readable. Right now the sandbox rules are set to allow read access by default on everything, but this is just a one-liner to change, which would cause the sandbox to generate an error if a file is read which isn't explicitly enabled. The container solution is going to be cleaner because it also helps curb errors from automagic build systems. These build systems wouldn't even be able to detect files not owned by a declared dependency. With the sandbox approach those files would be visible, but would generate errors when accessed (so at least we get a bug report, but users still have to deal with the issue). Sure, this would to some extent hide problems, but then again the automagic build system would be defeated all the same. The real question is how long it takes to extract those file lists and create all those bind mounts. In the case of @system some of this could be cached. I'm pretty sure the file lists would be quite fast - we only need to go one level deep on the dependency tree (I think). I suspect the bind mounts would be fast, but I haven't tried to benchmark it. I also have no idea how sandbox performs with a very long list of rules. -- Rich
