Re: Part 2: System Structure

[Bas Wijnen]

On Mon, May 15, 2006 at 01:15:21PM +0200, Pierre THIERRY wrote:
> > Also, allowing the game to just disappear in the middle of a
> > high-score update seems very bug-sensitive.
> 
> There is a design pattern that would avoid such bugs: the program on
> user's resources calls a service to update the data, and such a service
> should check if request was complete or not.
> 
> This kind of bug could only appear if the program updates the data
> itself.

Well, maybe the problem isn't as big as it seems to me, but what I see as the
problem isn't that it can't be done, but that there're so many developers who
all need to be convinced that this is the way to do it.

> > The high-score data is information, owned by the competition, but you
> > may use it a bit.  However, only according to the rules of the
> > competition.  Sounds like DRM to me...
> 
> I may not use information for the high-score a bit. I may read it and
> transfer it as I like, and I can only ask in a specific channel to add
> something in it.
> 
> That sounds very different from DRM to me. Maybe I'm misunderstanding
> what DRM is.

DRM is "digital rights management", or "digital restrictions management"
(which is saying the same thing, taking different defaults (no use/all use)).

For digital rights management:
- You have the right to read the data, and do what you want with it.
- You have the right to write the data through the game program.

For digital restrictions management:
- You don't have the right to write the data, except through the game program.

The music/film industry usually puts restrictions on reading/copying.
However, that isn't the only restriction which can be managed.

> > > > plus opaque resource donation,
> > > I don't know what you mean by this.
> > Revocably donating a piece of storage that the donor cannot inspect or
> > change himself.
> 
> OK. I don't see how to avoid it without a big overhead.

That's what we're trying to find out. :-)

If this case does show a need for opaque storage donation though, there is a
solution (for this case):  The user session can provide a service which
reserves a piece of storage.  It can guarantee that only the requestor gets a
capability for using it (although the session will keep one for itself, to
destroy it on user request).  The user can then provide the game service a
capability to its session.  The game service will then:
- verify with the session manager (the thing that creates sessions) if this is
  indeed a real session.
- verify with the session if this is indeed a capability to such storage
  creation.
- use it to create storage.
Note that this is possible only because the user session is part of the TCB.
Also note that this is a very special situation.  The user will not usually
give this capability to anyone, and so "normal" programs are not able to use
such services on their own: they need the user's explicit permission (in the
form of the capability).

> > Transparently giving away resources will definitely be possible
> > (that's when the donor can revoke, inspect, and change it).  For CPU
> > it doesn't matter.  There's nothing to inspect.  For storage there is
> > a difference.
> 
> Then the only solution is that the user only provides CPU and the game
> provides storage. But then sometimes the game won't be playable by
> players because too many of them are already playing. That doesn't sound
> like a good solution to me.

I think in practice it will be acceptable.  However, I also think that we
should do better than "it works in most cases".  So I agree that it isn't a
good solution.

> > > On my system, there are 79 of them just in /usr/games, for 472
> > > packages in the game section of Debian etch.
> > These are games that support a competition, I suppose.  In case we
> > agree that for those we don't actually want them to run on the user's
> > resources, I don't think there is a problem.
> 
> But we don't agree. ;-)

Aaah, and I so tried to use words which didn't imply that I agreed with the
statement... :-(  Ah well, I'll be explicit then: I didn't make up my mind
about it, and I tend to not agreeing with it as well.

> > > I also have 73 of them in {,/usr}/{s,}bin, though many of them are
> > > either abusive use of setuid/setgid or unnecessary in Hurd-NG, like
> > > mount or ping.
> > Actually, ping may need to be a service.  The reason it is on Unix is
> > that the user is not trusted with raw access to the network card.
> 
> Sure. For things like ping or traceroute, a Hurd-NG will be far more
> simple and secure.

Huh?  I wouldn't expect that it makes a big difference.  Why would it be any
simpler or more secure (except that they don't have access to the rest of the
system)?  We will still want to block "normal" user's access from "trusted"
ports, that is ports below 1024, so we can't give raw access.  Don't you
agree?

> > "writing an utmp entry" could be a service provided by the system.  I
> > don't think there should be any check that it is only called by a
> > "real" terminal.
> 
> OK, so those are not a problem.
> 
> What if the administrator wants to enforce some policy about what can
> update utmp, though? I think we fall back to the previous use case.

I suppose so.  Although I don't see why an administrator would want that.

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