[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Hurd SoC projects
From: |
olafBuddenhagen |
Subject: |
Re: GNU Hurd SoC projects |
Date: |
Fri, 30 Mar 2007 02:24:11 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Hi,
On Thu, Mar 29, 2007 at 10:35:00AM +0800, Wei Shen wrote:
> On 3/29/07, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net> 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-