From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <499f328d8dc6462edbadb7e4894feaf8@vitanuova.com> To: 9fans@cse.psu.edu From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] an idea Date: Wed, 21 Apr 2004 22:26:23 +0100 Topicbox-Message-UUID: 678cba4e-eacd-11e9-9e20-41e7f4b1d025 ok, this idea's a bit off the wall, but i thought i'd mention it because i think it's got some potential. some observations on the way 9p works currently: 1) if i import a remote namespace containing /srv, mounting a file in /srv triples the latency of requests on the mounted namespace (write tmsg, reply, read rmsg header, reply, read rmsg body, reply). 2) without re-mounting the connection, there's no way of introducing a new user to a remotely imported namespace. 3) the '#' namespace is quite restrictive (devices can't be attached by a remote machine, unless using an additional protocol, such as import), but also overly permissive (there's no way of arbitrarily restricting the set of devices available to sub-processes) 4) there's an arbitrary distinction between the '#' namespace and normal namespace, when kernel/user boundary is potentially largely arbitrary. you can't, for instance, substitute a user-level simulation of device x if a program accesses it via #x rather than a previously mounted instance of it. 5) there's a global idea of "user" (the user id of the current process, as used by fauth(2) at al) but in a situation with resources imported from many authentication domains, this isn't necessarily realistic. 6) kernel level devices are privileged in that they can access some user resources directly, in particular open fds and names. user level servers can't. here's the germ of a solution: put auth files in the namespace. here's how it might work: in your namespace you find a file with the DMAUTH bit set, an auth file. opening this produces a fid suitable for authentication, which can also be used as part of a later attach message, giving access to a new namespace - the namespace accessible as a result of this attach is distinct (files occupy a different qid space) but derived (the server decides what namespace to provide from the auth file used). imagine that /srv contains a load of these auth files. each one is like a gateway into a new namespace, in just the same way that the files in the current /srv are, except that the mount driver's job has already been done, so that someone mounting one of these remotely does not incur any additional latency over the network. moreover (and this is where things start to become interesting, i think), there's no particular reason why the auth files in /srv have to be 9p servers - they could be devices too. suppose, for the sake of argument, that it is possible to have a file descriptor that represents a walked-to-but-not-yet-open file (the kernel can do this already; an implementation would be trivial). suppose also that there are some of the usual 9p-like operations on such a file, such as walk, bind, open, etc. then imagine a device similar to the current /srv, except that any attach gives a new, clean instance, containing nothing at all, rather than globally shared resources, as currently. any file descriptor could be posted to this directory; a walk to it would give you back the original. when you boot the system, you bootstrap an instance of the /srv device, containing an auth file for each device compiled into the kernel, including the srv device itself. suddenly you don't need the '#' namespace any more. to do the equivalent of newns, attach to a new instance of the srv device, place within it the resources you want available after the newns (could include auth files, directories, etc), clear the namespace, and then bind the new instance of /srv (you'll still have its file descriptor around) onto /. for a subprocess, you can arrange exactly the set of devices that are available. there's also the potential to "push" an authentication scheme onto an auth file. in fact there are bucketloads of possibilities i haven't begun to think about yet. this kind of arrangement seems to me to make the namespace less arbitrary and more powerful. an auth file acts as a kind of tunnel to another namespace, but one that itself exists within the namespace, and is thus amenable to "meta-" namespace tools, such as iostats, cfs, etc. the implementation would be straightforward (main kernel change would be having a Dev* inside a Chan rather than indirecting through devtab), and it doesn't change 9p. almost all user-level code would be unaffected. quite a number of solutions to previously unpleasant problems seem to me to fall out from this, but i'm likely missing some blindingly obvious objection. what do you think?