[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: Sat, 13 May 2006 08:59:17 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Sat, May 13, 2006 at 06:57:04AM +0200, Pierre THIERRY wrote:
> Scribit Marcus Brinkmann dies 12/05/2006 hora 17:45:
> > System Services
> > 
> > Unix-style suid applications have been proposed as one application for
> > alternative process construction mechanisms. [...]
> >
> > In fact, no gain can derived from letting the user instantiate system
> > services. In Unix, system services run on durable resources, which the
> > user can not revoke.
> You make here the assumption that suid is only used for system services,
> but I have many suid games in my system, exactly for the purpose I
> described: letting these programs access the hall of fame without
> letting me accessing it otherwise.
> Can you propose a way to achieve this?

In both cases, there must be a trusted third (or actually second) party, which
is trusted to hold the sensitive data (such as in this case the hall of fame).
This party is the one providing the service.  For unix setuid, this is
typically "the system".  However, in the Hurd any normal user can of course
take that role.  And even if it is the system (because it is a
system-installed game), that doesn't mean security holes are opened, because
this service of course doesn't run with capabilities to anything it doesn't

I do see one problem with this approach though.  If the game is a service
provided by some server, then the user doesn't pay for the resources which are
used by the game.  With many services this is fine, but with games it is at
least conceptually wrong.


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]