Rich Freeman <ri...@gentoo.org> wrote: > On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth <mar...@mvath.de> wrote: >> Tim Harder <radher...@gentoo.org> wrote: >> >> It is the big advantage of overlay that it is implemented in >> kernel and does not involve any time-consuming checks during >> normal file operations. > > Why would you expect containers to behave any differently?
For overlay, there is only one directory to be checked in addition for every file access. For containers, at least a dozens of binds are minimally required (/usr /proc /sys /dev ...). But as you mentioned in your posting, if you want to take more care you easily have thousands of bind mounts. At least implicitly in the kernel, all of these binds must be checked for every file access. I am not sure whether this happens very quickly by hashing (so that essentially really only the creation costs time). As mentioned, I do not have actual timing results. I am just afraid that it might easily cost more than a context-switch which already gives a slowdown for fuse-overlay which is so large that I would not recommend it for a sandbox. > Now, I am concerned about the time to create the container, if we're > going to specify individual files, but the same would be true of an > overlay. [...] > to populate an overlayfs with just that specific list of files. No. For overlay you need only one mount (not even a bind) and only one directory traversal at the end to check for violations. The nice thing is that this is practically independent of the number or structure of directories/files you want to protect, i.e. it scales perfectly well. For the more fine-grained approach, you just delete the files you do not want to have in the beginning. Not sure, how quick this can be done, but once it is done, the slowdown when running the sandbox is independent of the number of deleted files (because here certainly only one hash lookup is required). Of course, as mgorny already observed, overlay alone is not an absolute protection (e.g. against writing to some /dev/...), so perhaps it is a good idea to use containers as an additional protection level. > If you just replicate the current sandbox > functionality then setup time is tiny I am not so much concerned about the setup time but more about the delay caused for file operations once the sandbox is set up. Perhaps even a dozen bind directories already give a considerable slowdown...
