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
