[Top][All Lists]
[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
signature.asc
Description: Digital signature
- Re: Part 2: System Structure, (continued)
- Re: Part 2: System Structure, Pierre THIERRY, 2006/05/15
- Re: Part 2: System Structure, Bas Wijnen, 2006/05/15
- Re: Part 2: System Structure, Pierre THIERRY, 2006/05/15
- Re: Part 2: System Structure, Tom Bachmann, 2006/05/15
- Re: Part 2: System Structure, Pierre THIERRY, 2006/05/15
- Re: Part 2: System Structure, Tom Bachmann, 2006/05/15
- Re: Part 2: System Structure, Bas Wijnen, 2006/05/15
- Re: Part 2: System Structure, Pierre THIERRY, 2006/05/15
- Re: Part 2: System Structure, Bas Wijnen, 2006/05/15
- Re: Part 2: System Structure, Pierre THIERRY, 2006/05/15
- Re: Part 2: System Structure,
Bas Wijnen <=
- Re: Part 2: System Structure, Pierre THIERRY, 2006/05/15
- Re: Part 2: System Structure, Tom Bachmann, 2006/05/16
- Re: Part 2: System Structure, Pierre THIERRY, 2006/05/16
- Re: Part 2: System Structure, Jonathan S. Shapiro, 2006/05/16
- Re: Part 2: System Structure, Jonathan S. Shapiro, 2006/05/16
- Re: Part 2: System Structure, Bas Wijnen, 2006/05/16
- Re: Part 2: System Structure, Jonathan S. Shapiro, 2006/05/16
- Re: Part 2: System Structure, Bas Wijnen, 2006/05/17
- Re: Part 2: System Structure, Bas Wijnen, 2006/05/17
- Re: Part 2: System Structure, Jonathan S. Shapiro, 2006/05/17