Date: Tue, 13 Mar 2018 18:31:41 -0400 From: Mark Saad <nonesuch@longcount.org> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Cc: Kristoffer Eriksson <ske@pkmab.se>, Theron <theron.tarigo@gmail.com>, Warner Losh <imp@bsdimp.com> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD Message-ID: <BACCA158-AB12-4DE1-B70A-2084FF2C5806@longcount.org> In-Reply-To: <CANCZdfoU1B4228RpwfupvdVN9RPCCug4p283xmkNwW7t-M9CjA@mail.gmail.com> References: <d7621074-acb4-c5b6-1efd-dc55b51586b1@gmail.com> <201803132055.aa28780@berenice.pkmab.se> <CANCZdfoU1B4228RpwfupvdVN9RPCCug4p283xmkNwW7t-M9CjA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 13, 2018, at 5:43 PM, Warner Losh <imp@bsdimp.com> wrote: > >> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <ske@pkmab.se> wrote: >> >> >>> On 13 Mar 2018 12:53:18, Theron <theron.tarigo@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 . http://netbsd.gw.com/cgi-bin/man-cgi?multiboot+8+NetBSD-current http://ipxe.org/ --- Mark Saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BACCA158-AB12-4DE1-B70A-2084FF2C5806>