GNU Info

(heroes.info)Global score file

---

Next: Game Prev: heroesrc Up: Running

---

Enter node , (file) or (file)node

Sharing a global score file
===========================

   In its default configuration, Heroes will create a score file in each
user's directory.  However you may want to share a global score file for
many users.  This can easily be done by redefining the filename used by
Heroes to read and write the score file.  This filename is a resource,
so it can be overwritten in an `heroesrc' configuration file.

   If you are the installer of Heroes, you can do this from the system
wide `heroesrc' with a line like the following
     setrsc: score-file $(sys-dir)/scores

   The same considerations apply to saved games (`saved-games-file').

   `$(sys-dir)' is another resource the value of which defaults to
`/var/games/heroes'.  According to the Filesystem Hierarchy Standard
this is the place where you should store modifiable game files.  If you
need to change this, simply add another `setrsc:' line:
     setrsc: sys-dir /site/var/games/heroes
   By the way, you will have to create the `$(sys-dir)' directory
yourself, because Heroes is not smart enough (and probably doesn't have
the right to create that directory anyway).

   Now you have to make several choices regarding the policy for
granting access to that file.  This is a global score files, so you
need to devise a setup which allows Heroes to write that file whoever
run the game.  The most straightforward way to allow this is to create
the `scores' file with `666' permission... you probably don't want to
do this because everybody would be allowed to damage the file.

   A cleaner idea is to create a special user or group to own that file,
and grant `heroes' the appropriate rights (set-user-id or
set-group-id).  Setting `heroes' as a set-user-id program is a security
problem, because if someone manage to get `heroes' to execute arbitrary
code, he can have the game overwriting itself.  So the correct solution
is to set `heroes' as a set-group-id program, and make the score file
writable only by that group.  At worse, if someone manage to break into
`heroes', s/he will only be able to damage the score file.

   Here is a sample setup where `heroes' is configured as a
set-group-id program for a group called ``games'':
     % cd /usr/games && ls -l heroes
     -r-xr-sr-x    1 root     games     2074633 Mar 25 22:29 heroes
     % cd /var/games/heroes && ls -la
     drwxr-xr-x    2 root     games        4096 Mar 25 22:35 ./
     drwxr-xr-x    4 root     root         4096 Mar 25 19:59 ../
     -rw-rw-r--    1 root     games        2291 Mar 25 22:35 scores
   Note that `/var/games/heroes' is not writable by group `games', so
you have to create the file `scores' before Heroes can use it.

   When `heroes' is run as a set-group-id or set-user-id program, it
executes some code to drop this privilege whenever possible.  Basically,
it will revert its effective-group-id and effective-user-id to the
player's group-id and user-id on startup and only switch back to it's
file-group-id and file-user-id when it needs to write to a file in the
`$(sys-dir)' directory.  This is what the `$(sys-dir)' resource is for:
a file which is beyond that directory is opened with the
file-group&user-id (i.e. group `games' in the above example), any other
file is opened using the player's group(s) and user-id.  The visible
consequence is that files created in the `~/.heroes' directory won't be
owned by group `games' (or whatever you chose).

   Finally, note that Heroes does keep track of how a resource has been
setup, and wont switch persona when `$(sys-dir)' or `$(score-file)' has
been setup in a non-trusted way.  Roughly, all hard-coded and
system-wide settings are trusted, while the user's personal settings
are untrusted.