From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <481af4553e8634d02adcbb5a858e926f@quanstro.net> References: <481af4553e8634d02adcbb5a858e926f@quanstro.net> Date: Tue, 14 Jul 2009 09:26:19 -0500 Message-ID: From: Eric Van Hensbergen 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: 1fc69498-ead5-11e9-9d60-3106f5b1d025 On Tue, Jul 14, 2009 at 8:23 AM, erik quanstrom wrot= e: >> Main annoyance is the lack of a proper srv device in Linux to >> facilitate sharing already open connections. =A0This is t a problem for >> per-user mounts --- but is a problem for private namespaces. =A0You can >> use p9p srv as mentioned elsewhere in this thread, but then you incur >> some additional overhead. > > unless this is unmanagable slowness, wouldn't worring about > performance at this stage only stand in the way of getting > something working? > Is something not working? My understanding of the situation is that many folks have a workable solution with p9p. The issues are ones of security, convenience and potentially performance. I'm not really a security expert, so I'll refrain from commenting on the first issue outside of the fact that there are concerns with the use of setuid applications, public mount points, and user-space managed connections to file systems (the latter only being a concern if the file system in question is the root partition). Outside of security, the option of tighter auth integration (via the keyring mechanism and fixing 9p.auth in v9fs) with the kernel module is primarily a convenience issue with a side-dish of performance. All that being said, I have no issues with the private mount approach, and have advocated it both via a paper (http://citeseer.ist.psu.edu/746023.html) and in the LKML mailing list discussions on removing privilege restrictions from the Linux mount system call. -eric