Hi, On Thu, Mar 29, 2007 at 10:35:00AM +0800, Wei Shen wrote: > On 3/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> If so, how can we handle the case that applications directly call > >> hurd_file_name_lookup to find a server? > > > >Interesting question... Of course, this case wouldn't be covered. But > >I wonder how likely applications are actually to attempt this, and > >whether it's a good idea to try to catch this if they do -- I'd guess > >such a situation would mean they want to do something very special. > > > Maybe, you are right. I have to further investigate before a > conclusion. > > But I still suspect it is not good for security reasons - we may want > a process to use a overriding server blindly. As I explained further down, *any* client-side solution is totally meaningless security-wise. This is not what the task is about, though. Even if you do it server-side, replacing a single server is useless for security purposes. To limit what a process can do, you have to replace *all* the default servers -- most notably the root file system. I suggest you just ignore any security considerations; that's really not what the server replacement mechanism is supposed to be used for. Note that once you have a different root filesystem -- which is inevitable if security is the goal -- replacing the other servers is trivial, without any further special mechanism. So this is mostly orthogonal to individual server replacement. On the other hand, that's actually one of the things I like about the proxy FS approach: It could be used in a very flexible manner, covering both cases: Replacing a single server for changed functionality, as well as creating totally isolated environments for security purposes. > And, I think in a micro-kernel based multi-server OS, we should > provide applications more flexibility rather than forcing the standard > lib and standard interface of a lib. No idea what you mean here :-( > >The server-side variant (approach 2) could enforce this. I'm not > >convinced though that implementing local namespaces in all the > >filesystem servers is a good thing. A more hurdish solutions seems > >using proxy filesystem servers. Also see my comment at > >http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00050.html > > > > I read it, but do not like the idea. I think it costs too much to > matain an entire namespace for each process. At least, for overring > limited default servers, it does not deserve the expense. It's not about having an own namespace for each process -- on the contrary. It's not like you run each process with a totally different set of default servers. Even if you want to replace some server, say auth, for all subprocesses in a group, that still requires only one proxy FS for all these processes. On a more generic note, the Hurd design generally encourages solutions using many processes. If this turns out to create performance problems, these problems should be fixed (using more light-weight processes), rather than compromising on the design. We will run into them again and again otherwise. > Thanks again for your advice. Discussion with you give me much help. Good to hear :-) I was a bit afraid that I might discourage you... -antrik- _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd