From owner-freebsd-hackers@freebsd.org Wed Mar 14 04:42:29 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 C23ACF5133E for ; Wed, 14 Mar 2018 04:42:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76ADF6A5F5 for ; Wed, 14 Mar 2018 04:42:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id d13-v6so2911668itf.0 for ; Tue, 13 Mar 2018 21:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hhBH1kK7bqc2h1/HS++Z+zsV7CP6vAUum7ZQHzt3hyY=; b=YWuxC54Oxx/O/syRLd05ec9pzoek7D+VR8Uu/oG96K92kazmqvsDWkoGyMES4HPHpI V9myk+zSPA0HNI3n4hJmDdjh8eD6Bq+mNw6JN1DhzJIwJ8Pr5NjmKbFIBjEYpnH8atMu Vc0qkRS/DdtdVBPLAWs7V6eFpziGvYNOrUrl2au0ieLLTQ67X8jGJIqOaBDQe7u/uFOO L37RrneDC1bH38JkijKqax316dIDUtTwgp+JGDyVI+eJaZRPTcMUcQY9lno8SGRfXu6T YLcA9Dkm86HiO+SWp9F7kdyAGvCeYhE7rNgJuETOfufTjF5B6CxMOvaYi9KoQMFTtUXk V3eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hhBH1kK7bqc2h1/HS++Z+zsV7CP6vAUum7ZQHzt3hyY=; b=sRW/gRJa8oINHGb5Chhyp2bhMdw0y70UXSrpS82a38W0ZdHg6MJEk9sGOf+Momnp4W 9EvhbknRnyDwVr8aqyZ9e+PCeFqEX5mzMu+vUzVK6XA9Hjw6bUH3/+0GX1yhnwrMl/qL gNaamSszDUCgFh8NfhIsZMLP3wI9JjKt1xbqnHQIaN8dHE7mGH+Nws6iIqE8SonCIDQv nQhJdHu1xx0PtYhPL8A/mDKTQOijPL9wx8r2HlcHHmvMx9+ofMMVq/g3bvq/X2a1erlo XM0fT2xQDIiRBcKBSADVb6pMBxB3ywS77LGClCY0eTYm+1QdCNQbS7ePtL6YfJTnzIdz RnFA== X-Gm-Message-State: AElRT7HcuB85zj/p5Dk96GWNFnOLEsyLWRvm0RE4B/gx1mPhdf65Z9TN 0xVWpTd8gtADIL9YhQZW/Z8N8bWqqLk/P22gl/jgjA== X-Google-Smtp-Source: AG47ELv9XI5gZTvrfJatSHH84d2bXvTfzpqC4OHyaT5wnLiebLp+Yub25iGjPz05hpWsQp2KCPfeqhe7OHbVN2G2kf8= X-Received: by 10.36.148.204 with SMTP id j195mr523044ite.1.1521002547633; Tue, 13 Mar 2018 21:42:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 13 Mar 2018 21:42:26 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> References: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 13 Mar 2018 22:42:26 -0600 X-Google-Sender-Auth: lmywJe67OJFh-RSC2iksixVx48s Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: "Rodney W. Grimes" Cc: Mark Saad , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 04:42:29 -0000 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 > > 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 < > ske@pkmab.se> 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 > 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