l4-hurd
[Top][All Lists]
Advanced

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

Re: Part 2: System Structure


From: Bas Wijnen
Subject: Re: Part 2: System Structure
Date: Tue, 16 May 2006 00:47:48 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Tue, May 16, 2006 at 12:09:46AM +0200, Pierre THIERRY wrote:
> > That's what I sketched using the user session.  If you build it into
> > the space bank, a program could decide that it allows opaque storage
> > for its child.  I want to avoid that.
> 
> I'm not sure I see how to implement in outside the space bank, and I'm
> not sure I see what you want to avoid... Could you elaborate?

What I want to avoid is this:
- User starts program P
- Program P calls server S, which needs storage
- P provides some of its storage, and makes it opaque
- User cannot inspect and/or change his own storage, because P opaquified it.

If this is a standard operation of a space bank (that is, one that you get
access to when you create a new sub-space bank), then this is possible.  What
I want is that the space bank doesn't support opaque subspace banks, so the
way to implement one is to make sure all parents are part of the TCB.  In
particular, having the user session as the direct parent would be a way to do
it.

> > If the default is to use opaque storage, then that dialog would be
> > very annoying (popping up at every single process instantiation)
> 
> Why the hell should it be the default?!

Because it is in EROS, AFAIUI.  As far as changes aren't specified I'm
assuming the EROS implementation (as far as I know about it).

Thanks,
Bas

-- 
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 http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

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