user-writable content in games

[Wart]

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