From owner-freebsd-hackers@freebsd.org Wed Mar 14 03:33:39 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 02CA7F4B55D for ; Wed, 14 Mar 2018 03:33:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 835AC86828 for ; Wed, 14 Mar 2018 03:33:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id d21so2637070ioc.5 for ; Tue, 13 Mar 2018 20:33:38 -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=D89aR3bhuucToua4/lmglmVZMgyoOR/Kz54243ILgfU=; b=miY1UeaPkMgzmU0WTc1mG4+NyzGKaM/aO0tYC3G9+bTj/CZIXRUguP9PzVBHNWlqzV SRiEOMycBqxtBW7R3BTT0pKbSpAWu8OQKA77y+aj0e5sPGxHFJLMfIJkVxY7w3ypPz/D e2gL4i7X8+pcrm79N+EkNOnVWXivaHsL4rvQHq1Ev5nhNqId2lrgDx7tZKHInBOLhSJo GwOv8oOXV7Tanm789ItEpCog2ED6/UcI4dpDKO+xJFbxKf4THcyCgKVtpCHhnfXOdiO5 rHykLumR16NbWNi+gpYSlZIGLqPibBj5H5qYT9KdDTaXgRCnqhyL0aYC2BE8AzDnBaP5 gfZQ== 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=D89aR3bhuucToua4/lmglmVZMgyoOR/Kz54243ILgfU=; b=LxIP0PICxXj7q/r46CawfPVn9h/tXOXiGn1qsJkSOd8GByWgdmXWiT+JsHsFNmqpZu 3CfOsW8sNP2ZVZ+NL3C2vsILPbtGgym8Is47+Y0fS7s05bgZi4hs77l/4x6Djx0cIrDh 5vB89g1GcSACVd7fBnlxL4LetYEpok3EEWhVIixMLJGIf8ukIuaNu5FaJWkqIu5ltig5 19sFkMoSXhDfADLcHwhUziS7+N2hzZBE79v10r0lCfAwJTYlXlLKeVlYj7dvqkOGFfUo mFkOljKYoNLmeN/tx6/ExPDXt/HFPvhuQUWZcxFb0NljrNae341kedr2sCu20SnufNiG Yh0g== X-Gm-Message-State: AElRT7FpJd0LqkVIZeMonKX60NpcphPgttpCDOeVHBbSuU0T4chWs5tH PKs4ieBia0qwpyty3xXZSoFJfA3H8SaJDf3dOGKMrA== X-Google-Smtp-Source: AG47ELsaSmvWeGqVyVP+z8NQ68/z5oi9a5bhecQGInw1lrmtrwSG56aYb4ItBQ1b4iVysGd0dJj/3uzCJvtjyB4SvRs= X-Received: by 10.107.187.129 with SMTP id l123mr3077686iof.39.1520998417713; Tue, 13 Mar 2018 20:33:37 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 13 Mar 2018 20:33:36 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <201803140125.w2E1Ps8j085810@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 13 Mar 2018 21:33:36 -0600 X-Google-Sender-Auth: SmrkznN5QMKFHFiZvQXflz8z_zA Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Mark Saad Cc: "Rodney W. Grimes" , 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 03:33:39 -0000 On Tue, Mar 13, 2018 at 7:35 PM, Mark Saad 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 > 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 > > 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 FreeBSD takes all the arguments that DHCP supplies as loader / kernel env variables (and if that's not working, I'll fix it). This is a recent feature and might not be widely documented. Warner > > ... > > > > 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@freebsd.org > > > > -- > mark saad | nonesuch@longcount.org >