Date: Tue, 13 Mar 2018 22:42:26 -0600 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: Mark Saad <nonesuch@longcount.org>, 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: <CANCZdfrpSUX9NMkzJuHtJY2ySkdOYE_61RT4C%2BgNnfZAT_mUNA@mail.gmail.com> In-Reply-To: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> References: <CAMXt9NbsZ%2B2K4JhBOvEWVGoa5tq5PeUY6=ab=MOW1M47RJOeMw@mail.gmail.com> <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 13, 2018 at 9:53 PM, Rodney W. Grimes <
freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes
> > <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote:
> > >> > 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.
> > >
> >
> > I think you are both missing my point. I can boot FreeBSD with ipxe
> > loading mfsbsd style setups like this
> >
> > :freebsd
> > initrd ${base-root}/freebsd/mfsroot.gz
> > chain ${base-root}/other/memdisk harddisk raw
>
> Nope, not what I am doing.
>
> > I want to be able to boot and run it like I would Linux or ESXi with
> > the ability to directly load an kernel and a mfsroot/initrd and pass
> > kernel loader arguments
> >
> > :centos674
> > set centos674_args edd=off ramdisk_size=50000 nomodeset
> > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks
> > ksdevice=${net0/mac} verbose ip=dhcp
> > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0
> > nousb
> > echo ${centos674_args}
> > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz
> ${centos674_args}
> > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img
>
> :freebsd6411
> set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64
> iseq ${platform} efi && chain nfs://192.168.48.38/B/FreeBSD/
> 11.0/amd64/boot/loader.efi || chain nfs://192.168.48.38/B/FreeBSD/
> 11.0/amd64/boot/pxeboot
> boot || goto failed
> goto start
>
> I agree it would be nice to get the "variable=value" stuff working.
> I do know the above does infact pass that root-path to the kernel,
> and without that mountroot fails, so some of this is working
>
right, loader.efi and/or pxebooot is what sets the root path (and other
variables). What others are asking for is some kind way to do just load
the kernel + a bundle of variables with some kind of 'mini /boot/loader'
(in our terms) that can turn the bundle into the metadata the kernel needs
to do it's job. We have an extra layer of with loader.efi/pxeboot and linux
doesn't...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrpSUX9NMkzJuHtJY2ySkdOYE_61RT4C%2BgNnfZAT_mUNA>