From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <0F3972F5-D44B-4231-97FA-C6CE871B032B@gmail.com> <140e7ec30907130124g1a0e4c90m6d83a08516d95463@mail.gmail.com> Date: Mon, 13 Jul 2009 18:18:38 -0400 Message-ID: <3aaafc130907131518y74523ef8rf9ddb92fb3d3d105@mail.gmail.com> From: "J.R. Mauro" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] v9fs question Topicbox-Message-UUID: 1de53fda-ead5-11e9-9d60-3106f5b1d025 On Mon, Jul 13, 2009 at 6:05 PM, Eric Van Hensbergen wrot= e: > On Mon, Jul 13, 2009 at 4:45 PM, hiro<23hiro@googlemail.com> wrote: >> When I need remote access I nowadays use v9fs+ssh. >> Multi-user auth in kernel like you propose sounds nice and consistent, >> but too complicated. It doesn't fit linux, and thus an additional >> deamon would mean one more place of security relevant code prone to >> bugs. >> > > While I agree with that being the state of things today, it doesn't mean > we shouldn't push for better. =A0Maybe the Glendix folks will make things > consistent (and bug free). We hope to. One of the reasons it would actually be unwise to let anyone mount anything now is that no one uses per-process namespaces. That's probably fine on your desktop, but not on a server where 20 people try to mount something under /mnt/foo or whatnot. On the security side, I helped get the plan9-style authentication device in the mainline kernel. It's in staging. I guess the PAM module is 90% done, but they need some help if anyone is interested. > >> >> From a security (and perhaps simplicity) point of view userspace >> authentication sounds more reasonable to me, p9p together with >> something like fuse (even together with the new userspace hackery) or >> perhaps a single-user v9fs combined with inferno for doing the >> auth/crypt work seems a lot more reasonable to me than additional >> clever hackery from the plan9 side. Not sure if somebody has something >> like this working already... >> > > I have a variant using Inferno right now, mounting the file system direct= ly > from the stdin/stdout of the emu. =A0Combined with private namespaces it > provides a seemingly secure mechanism for accessing remote resources > as well as providing local resources to remote cpu services. > > =A0 =A0 =A0 -eric > >