And in this case, you need to make the suid root executable *only*
execute scripts from a certain directory (not an option that the user
passes in), then make that hard-coded directory owned by root. The
directory itself should only be root-writable (so no new files can be
added by others), and the files in it should also be only root
writable. This is the only way to securely execute scripts from
within a suid root binary. And of course, the binary itself must be
only root writable.
Unless you are VERY careful, there is no way to make a suid binary completely
secure. Games are notoriously complicated pieces of code which can be
exploited. Scripting systems are even more dangerous. Never trust a
game as a secure set-uid program on a system where security is important.
However, on single-user home systems with no network access, feel
free to do what you like.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Back to the topic this thread originally started on…
I just wanted to thank everyone for their input. I got the
frame rate up acceptably high. On my laptop (P-150MMX) the
frame rate at 640x480x8bpp is around 60fps, that’s up from
4.8fps And on my big machine (PII-450) it’s around 250fps
(up from 18fps)
After I clean it up a bit, add some features (loading/saving
maps, multiple sprite tables, stoping out a few bugs that crept
in (it has a nasty memory leak right now) I’ll release it.
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
Err, I think there's another problem, I'm using for my OpenVentura
Isometric Game Developement System embeded python, so ? the python code
is executed as root ! ? anyone can do anything !
So by the time, everyone want to use a extension language cant chroot
his game…
well, im not sure but...
Letter writen for Malaga / Spain, we're in our mayor fest "la feria"
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
Err, I think there's another problem, I'm using for my OpenVentura
Isometric Game Developement System embeded python, so ? the python code
is executed as root ! ? anyone can do anything !
So by the time, everyone want to use a extension language cant chroot
his game…
well, im not sure but...
Letter writen for Malaga / Spain, we're in our mayor fest "la feria"
