Hans de Goede wrote:
Wart wrote:
>I've come across two games so far that allow user-contributed content,
>but am unsure of how to proceed with the file permissions.
>
>The first game, njam, has an in-game editor for users to create new
>levels. The directory where user-levels are saved is
>/usr/share/njam/levels.
>
>The second game, hack (part of bsd-games), creates 'bones' files when a
>character dies. These bones files are later loaded and removed when
>other players start a game to create ghosts and treasure piles.
>
>In both cases this user-contributed content needs to be placed in a
>directory that is writable by the game binary. This is similar to the
>shared scoreboard file, except that in both of these cases the name of
>the file is not known in advance, so we can't open a setgid filehandle
>when the game starts up and then drop setgid.
>
>hack works around this by not dropping setgid so that the app is free to
>create new files in the content directory, which isn't the safest thing
>to do.
>
>Does anyone have any ideas on how we can allow this user-contributed
>content without sacrificing too much security in the games?
>
I _really_ believe we shouldn't try to wrangle ourself into all kinda
corners for things like this. Either we can solve things simply, or we
should try to not solve them at all.
My suggestions for the 2 given examples:
-just give hack its own private group and let it run as that, that
reduces the risc to:
-someone manages to get hack-rights
-this someone uses those rights to create malformed input files for
hack
-if someone-else runs hack these malformed input files could cause hack
todo unwanted stuff with someone-else's rights.
Then the question becomes is this an acceptable risk, we could make the
risk even smaller by implementing the suggestions done by Jason so that
the files can be opened immediatly in main and rights dropped, if we do
things Jason's way we probably don't even need a seperate hack user.
The more I work on hack, the more I realize how tricky this one is. I
was able to make a patch to deal with the bones files, and the
scoreboard file, but then ran into problems with file locks. It seems
that hack wants to use hardlinks to create a file lock to prevent
concurrent writing. It also wants to create a lock file to prevent two
people from playing simultaneously under the same name. While I might
be able to make a patch to work around all of this, it is quickly
becoming nontrivial and pretty invasive. I'm starting to prefer this
custom gid solution...
-for njam, teach it to save and look for levels under $HOME, if a
user
wants to share his levels he can just give them to other users to copy
to their level dir, or ask his sysadmin to put them in the global dir,
why should we assume he wants to share them and jump through hoops to
automaticly share them for him?
That sounds fair enough. I still think a njam-install-level command
would be useful, but it's something that upstream could provide.
--Mike