Date: Tue, 13 Mar 2018 18:25:54 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Mark Saad <nonesuch@longcount.org> Cc: Warner Losh <imp@bsdimp.com>, Kristoffer Eriksson <ske@pkmab.se>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Theron <theron.tarigo@gmail.com> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD Message-ID: <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <B0D77EC9-16C0-4A47-99CD-3F9B3FC5FC28@longcount.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Mar 13, 2018, at 7:16 PM, Warner Losh <imp@bsdimp.com> wrote: > > > > > > > >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <nonesuch@longcount.org> wrote: > >> > >>> 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 . > > > > There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works... > > > > Warner > > I am going down the rabbit hole to see how it works . If you have any questions I am happy to share my working tooling. ... isc-dhcp from ports, base system tftp setup via inetd some bits of syslinix 6.03 proper set of iPXE.exe binaries built with iSCSI, http and nfs support, you wont need iSCSI, I use that for other things like Windblows. I boot direct from iPXE to nfs loaded kernel, only thing tftp is used for is getting a modern version of iPXE onto the booting system. iPXE loads a menu.ipxe to allow OS selection. menu.ipxe loads /boot/pxeboot via NFS YOU SHALL HAVE ISSUES HERE most pxeboot images are broken pxeboot loads kernel via NFS kernel runs, end up in /etc/rc.diskless that does the rest of the magic. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803140125.w2E1Ps8j085810>