bug-hurd
[Top][All Lists]
Advanced

[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, address@hidden <address@hidden> 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-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]