GSoC Idea: per-process filesystem namespaces for FreeBSD

[Warner Losh]

On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <nonesuch at longcount.org> wrote:

>
> On Mar 13, 2018, at 5:43 PM, Warner Losh <imp at bsdimp.com> wrote:
>
> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <ske at pkmab.se> wrote:
>
>
> On 13 Mar 2018 12:53:18, Theron <theron.tarigo at gmail.com> wrote:
>
> 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 ...
>
>
> What if I mount a new /etc with a passwd file where root has no
>
> password, and then run "su"?
>
>
> (How does Plan9 handle that?)
>
>
>
> Plan9 handles that by having a daemon that does user authentication. It's
> actually more complicated than that, but the machine owner has control over
> who can do what. For this to work in FreeBSD, either we'd need to disallow
> the 'file' type for passwd, or we'd have to do something sensible with
> setuid programs. Well, maybe not 'or' but 'and' since the security of
> setuid programs depends on the security of the filesystem.... Plan 9
> doesn't have these complications, so it can offer a user malleable
> filesystem without security risk.
>
> Warner
>
>
>  A kind of related task; FreeBSD could benefit from : Fixing  and
> improving unionfs / nullfs. There are some weird issues with the current
> unionfs and while it works in many cases there are some edge cases where
> the comments are something like “ FreeBSD needs a proper stacking vfs ...”
>   the examples I can think of ; imagine you have a jail , chroot or even a
> Pxe booted system where you want a a read only null mount from the hosts
> /bin to the targets /bin . Now expand that to most of the base system and
> the mount tmpfs’s for /tep /var/log etc.  most of that works but try to
> unmount it in the wrong order or thrash a unionfs with lots of writes ,on
> top of a tmpfs and things break .
> So to be clear the project would be to better document the various uses of
> unionfs and nullfs that work , for the ones that do not diving into the
> stacking vfs and seeing if it could be implemented and if it would help .
>
> Alternatively making FreeBSD multiboot compliant would rock . This would
> allow FreeBSD to natively boot from ipxe or syslinux derivates; thus
> allowing you to boot a working FreeBSD install via a kernel and mfsroot
> image off a web server .
>

There appears to already be a multiboot.c in the bootloader. I've been told
by others in the past it just works...

Warner