Date: Tue, 13 Mar 2018 20:53:17 -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: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CAMXt9NbsZ%2B2K4JhBOvEWVGoa5tq5PeUY6=ab=MOW1M47RJOeMw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803140353.w2E3rHN1086319>