It occurred to me that you could fix the hack bone file issue by using some sort of structured format and storing all of the bone information in a single file.

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?

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.

-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?