GSoC Idea: per-process filesystem namespaces for FreeBSD

Konstantin Belousov kostikbel at gmail.com
Tue Mar 13 18:50:57 UTC 2018


On Tue, Mar 13, 2018 at 12:53:18PM -0400, Theron wrote:
> Hello All,
> 
> I am an undergraduate a Boston University looking to contribute to 
> FreeBSD this summer under GSoC.
> 
> The idea I would like to implement is to bring to FreeBSD a per-process 
> mounting / namespaces functionality similar to that of the Plan9 
> operating system as a means to give greater flexibility in combination 
> with less overhead than is associated with chroots and jails for 
> purposes of isolating software setups from one another and from the 
> underlying system.
> 
> For those unfamiliar with Plan9, here is a rough explanation of the 
> namespace feature: unlike in Unix, where all processes share the same 
> virtual filesystem, each process instead has its own view of the 
> filesystem according to what has been mounted, which, unlike Unix mount, 
> as an unpriviliged operation changing only what is seen by the 
> particular process and any processes it later spawns.  Thus it is 
> possible for one process's /bin to be completely different from another 
> process's /bin, and neither need be the same as the system's /bin, 
> should one exist.
> 
> As an example of its application and potential usefulness, a user may 
> mount on top of /usr/local an overlay pointing to a location owned by 
> the user, allowing existing binary packages which expect a /usr/local 
> PREFIX to be installed and run without any modification either to the 
> binary packages or to the underlying system.  Currently the only ways to 
Do you understand what consequences of this feature is, when mixed with
setuid ?

> achieve this are by recompiling ports with a different PREFIX or by 
> configuring a jail.  Some, but not all, programs will function 
> out-of-place under tweaked PATH and LD_LIBRARY_PATH, but this is not a 
> general solution and leads to messy environments.
> 
> Although I have not previously worked with kernel programming in 
> particular, I have good experience of high-level practices and low-level 
> details of C programming and I can teach myself new technical details 
> quickly.  In researching how to approach the task, I will study the 
> existing implementation of chroot, jail, and fdescfs as examples of 
> process-specific namespace behavior already supported in FreeBSD 
> kernel.  The nullfs and unionfs may also serve as work to build off of, 
> although unionfs as currently implemented appears to be partially broken.
> 
> Robustness of the implementation allowing, it should eventually be 
> possible to replace system directories /bin, /sbin, /etc, etc. with 
> bindings configured at boot time to improve the safety of live system 
> upgrades and to provide a means of returning to older configurations 
> which is not dependent on filesystem-specific snapshotting features.
> 
> Although per-process filesystem namespacing is unconventional in the 
> face of the dominant Unix single-namespace model, introducing the 
> feature to a Unix-like system does not constitute a radical change, as 
> it is compatible with and indeed facilitates the meeting of the 
> reasonable expectation of existing and unmodified software to find 
> resources in predetermined file paths.
> 
> My attempt here to outline the relevant concepts is to the best of my 
> limited understanding.  Hopefully I am not creating or propagating any 
> misinformation and have not grossly misassessed the complexity of the task.
> 
> I would greatly appreciate any suggestions of approaches to this task 
> and of who to contact for more expertise and for potential mentorship.

You need to understand a lot about the FreeBSD VFS to sketch the
approach for implementation.  I do not want to sound sceptical, but
the amount of architectural work, and then the quantity of the details
to discover and handle for this project certainly exceed the scope of
GSoC.

If you can formulate the basic ideas of the possible implementation, this
might add more substance to the discussion.


More information about the freebsd-hackers mailing list