[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sawmill's dataspaces and the Hurd's physmem

From: Bas Wijnen
Subject: Re: Sawmill's dataspaces and the Hurd's physmem
Date: Mon, 5 Sep 2005 12:24:10 +0200
User-agent: Mutt/1.5.10i

On Mon, Sep 05, 2005 at 11:15:46AM +0200, Ronald Aigner wrote:
> It appears to me that a file system server providing a file to a client
> always belongs to that client's trusted computing base. The FS server
> has to belong to the client's TCB, because it will provide the client
> with the content of a file. It may alter that content in any possible
> way before handing it to the client.

There are several levels of trust.  The client must trust the filesystem to
give data it wants to handle, no matter which route it uses to actually get
the data.  Trusting the server so much that it's allowed to hang, crash, or
even take over the client is a completely different level of trust.

System servers such as physmem automatically get that trust, because there is
nothing you can do about it.  Physmem can just change your executing code if
it wants, for example.  However, for a filesystem (and especially one from an
other normal user) such trust is not a good idea.

What we call "trusting a process" in the Hurd (which is something we want to
avoid usually) is a lot more than accepting data for display to the user, for
example.  If the user wants to start executing that data, then appearantly he
trusts the source, so it should be good.  But if he doesn't, then we shouldn't
force that trust on him.

Bas Wijnen

I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see

Attachment: signature.asc
Description: Digital signature

reply via email to

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