Date: Tue, 13 Mar 2018 21:35:04 -0400 From: Mark Saad <nonesuch@longcount.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> 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: <CAMXt9NbsZ%2B2K4JhBOvEWVGoa5tq5PeUY6=ab=MOW1M47RJOeMw@mail.gmail.com> In-Reply-To: <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net> References: <B0D77EC9-16C0-4A47-99CD-3F9B3FC5FC28@longcount.org> <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net>
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> w=
rote:
>> >>
>> >>> 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 th=
e
>> >>>>> namespace feature: unlike in Unix, where all processes share the s=
ame
>> >>>>> 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 contr=
ol over
>> >>> who can do what. For this to work in FreeBSD, either we'd need to di=
sallow
>> >>> the 'file' type for passwd, or we'd have to do something sensible wi=
th
>> >>> setuid programs. Well, maybe not 'or' but 'and' since the security o=
f
>> >>> 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 imp=
roving unionfs / nullfs. There are some weird issues with the current union=
fs and while it works in many cases there are some edge cases where the com=
ments are something like ? FreeBSD needs a proper stacking vfs ...? the e=
xamples I can think of ; imagine you have a jail , chroot or even a Pxe boo=
ted system where you want a a read only null mount from the hosts /bin to t=
he 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 us=
es of unionfs and nullfs that work , for the ones that do not diving into t=
he stacking vfs and seeing if it could be implemented and if it would help =
.
>> >>
>> >> Alternatively making FreeBSD multiboot compliant would rock . This wo=
uld allow FreeBSD to natively boot from ipxe or syslinux derivates; thus al=
lowing 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
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=3Doff ramdisk_size=3D50000 nomodeset
ks=3D${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks
ksdevice=3D${net0/mac} verbose ip=3Ddhcp
root-path=3D${centos-root}/CentOS6.7_x64/OS/ net.ifnames=3D0 biosdevname=3D=
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
> ...
>
> 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@freebs=
d.org
--=20
mark saad | nonesuch@longcount.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMXt9NbsZ%2B2K4JhBOvEWVGoa5tq5PeUY6=ab=MOW1M47RJOeMw>