From owner-freebsd-hackers@freebsd.org Wed Mar 14 03:53:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65D39F4D017 for ; Wed, 14 Mar 2018 03:53:24 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE8C0680F3 for ; Wed, 14 Mar 2018 03:53:23 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2E3rIq4086320; Tue, 13 Mar 2018 20:53:18 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2E3rHN1086319; Tue, 13 Mar 2018 20:53:17 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD In-Reply-To: To: Mark Saad Date: Tue, 13 Mar 2018 20:53:17 -0700 (PDT) CC: Warner Losh , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 03:53:24 -0000 > On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes > wrote: > >> > On Mar 13, 2018, at 7:16 PM, Warner Losh wrote: > >> > > >> > > >> > > >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad wrote: > >> >> > >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh wrote: > >> >>> > >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson wrote: > >> >>>> > >> >>>> > >> >>>>> On 13 Mar 2018 12:53:18, Theron 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