Date: Tue, 13 Mar 2018 18:31:41 -0400 From: Mark Saad <nonesuch@longcount.org> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Cc: Kristoffer Eriksson <ske@pkmab.se>, Theron <theron.tarigo@gmail.com>, Warner Losh <imp@bsdimp.com> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD Message-ID: <BACCA158-AB12-4DE1-B70A-2084FF2C5806@longcount.org> In-Reply-To: <CANCZdfoU1B4228RpwfupvdVN9RPCCug4p283xmkNwW7t-M9CjA@mail.gmail.com> References: <d7621074-acb4-c5b6-1efd-dc55b51586b1@gmail.com> <201803132055.aa28780@berenice.pkmab.se> <CANCZdfoU1B4228RpwfupvdVN9RPCCug4p283xmkNwW7t-M9CjA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 13, 2018, at 5:43 PM, Warner Losh <imp@bsdimp.com> wrote: >=20 >> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <ske@pkmab.se> wrote= : >>=20 >>=20 >>> 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 ... >>=20 >> What if I mount a new /etc with a passwd file where root has no >> password, and then run "su"? >>=20 >> (How does Plan9 handle that?) >>=20 >=20 > Plan9 handles that by having a daemon that does user authentication. It's > actually more complicated than that, but the machine owner has control ove= r > 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. >=20 > Warner A kind of related task; FreeBSD could benefit from : Fixing and improving u= nionfs / nullfs. There are some weird issues with the current unionfs and wh= ile it works in many cases there are some edge cases where the comments are s= omething like =E2=80=9C FreeBSD needs a proper stacking vfs ...=E2=80=9D t= he examples I can think of ; imagine you have a jail , chroot or even a Pxe b= ooted 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 t= mpfs=E2=80=99s 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 t= mpfs and things break .=20 So to be clear the project would be to better document the various uses of u= nionfs and nullfs that work , for the ones that do not diving into the stack= ing vfs and seeing if it could be implemented and if it would help .=20 Alternatively making FreeBSD multiboot compliant would rock . This would all= ow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing y= ou to boot a working FreeBSD install via a kernel and mfsroot image off a we= b server . http://netbsd.gw.com/cgi-bin/man-cgi?multiboot+8+NetBSD-current http://ipxe.org/ --- Mark Saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BACCA158-AB12-4DE1-B70A-2084FF2C5806>