Re: Part 2: System Structure

[Bas Wijnen]

On Mon, May 15, 2006 at 03:12:22AM +0200, Pierre THIERRY wrote:
> > On the one hand, you want to run the competition on the users
> > resources, on the other hand, you want the competition to be able to
> > reliably update the high score file.
> 
> I indeed want to program to run on user's resources, and I want that the
> program I choose be the only way to have write access to some data.
> That's the abstract scenario.

Of course this means that while the program runs, these resources are no
longer fully owned by the user (using Marcus' definition of owning): The user
cannot debug the program anymore.  It may not be unreasonable to say: the
entity which demands such things of the resources will have to provide them.

Also, allowing the game to just disappear in the middle of a high-score update
seems very bug-sensitive.

> > In these requirements you are already presupposing DRM
> 
> No I ain't. Or I don't know I am.

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...

> > 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.

> Someone answered me in private that giving resources to a server for it to
> process a request was already considered for Hurd-NG.

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.

> Do you mean giving CPU/storage to a server along with the request won't
> be possible in Hurd-NG?

I think he means only the opaque version.  I tend to agree, although some
better explanation would strengthen my view (or change it, depending on what
is explained. ;-) )

> > plus a careful competition program design that runs some parts of the
> > competition on durable resources and some on non-durable resources
> 
> I'm not sure I presupposed anything like that, because I'm not sure I
> understand what you mean. ;-)

The high-score storage must run on durable resources.  That is, the user must
not be allowed to revoke it.  But you want the game to run on the user's
resources which can be revoked at any time, and are thus not durable.

The "careful" part in Marcus' comment is quite significant IMO, because given
the number of games that would want to use this approach, it is very likely
that a lot of them get it wrong.

> > All of this is technically possible, but the complexity is inherent in
> > the goal.
> 
> But maybe there are some goals that we should support that fit in this
> use case. Just check every setuid/setgid executable in a system with a
> fairly large number of packages installed and check how you would deal
> with it...
> 
> 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.

> If you intend to have Hurd-NG used on typical desktop systems with
> typical people (that is, that might want reliable competition software
> on their system), then you have a problem here, I think.

I don't think so.  Without any resource accounting at all, simply assuming
infinite memory and HD space and crashing horribly when that assumption
doesn't hold, typical people would be quite happy.  That's how it works now
after all.  And we're doing _a lot_ better than that.

And I don't see why there would not be "reliable competition software" when it
runs on resources owned by the competition.  In fact, due to the
bug-sensitivity that comes with non-durable resources, I think it will be more
reliable.

> 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.

> There are some terminal emulators in them, which maybe fit the use case:
> they write utmp data. I don't know if it is of any importance for
> Hurd-NG.

"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.
If a user gives this capability to a program, then appearantly that program
can tell when the user opens a new "session".  That is, we do want to allow
users to write their own terminals, and they shouldn't need the system
administrator to get them registered so they can write to utmp.

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