[SDL] faster way?

Warren Downs warren at businesslink.com
Tue Aug 17 12:01:38 PDT 1999


     To solve this, I would write a wrapper (script or binary) that 
     retrieves the correct home directory before running the suid game 
     binary.  If you don't want people running the binary directly, require 
     a parameter (say, the real home directory), and if not provided, give 
     a message about needing to run <wrapper> instead.  The wrapper would 
     of course provide that parameter to the suid binary.
     
     One additional design method would be to make a general game engine 
     that runs suid root and can access the screen via DGA.  Then, have the 
     main game program, which provides the game's "character", as a 
     separate binary, which communicates with the suid root binary via an 
     IPC method, feeding it the graphics, sound, etc.  Basically the same 
     idea as X, except moving the rendering engine across the IPC barrier.
     
     Warren
______________________________ Reply Separator _________________________________
Subject: Re: [SDL] faster way? 
Author:  <sdl at surfnetcity.com.au > at internet-mail
Date:    8/17/99 10:17 AM


Warren Downs wrote:
     
>      If the program is going to be running on a single-user home machine 
>      (as most games do), security isn't such a great concern.  In this
>      case, you can provide an install program that makes the game
>      executable suid root (giving appropriate warning to the user).  Of
>      course, the install itself must be run as root, but that's normal for 
>      installing shared binaries.  You can have your installer detect if
>      it's not run as root, and in that case, warn the user that they won't 
>      get the increased performance of DGA unless they manually make the
>      game binary suid root.
     
Except security issues, running as suid root has one more disadvantage : meaning
of
$HOME changes so if your game saves something  e.g. in ~/.mygame it will be 
saved
in root's home directory :-(
     
     
     
     
     





More information about the SDL mailing list