[Pkg-games-devel] Another joiner!

[Steve Kemp]

On Fri, Jan 13, 2006 at 03:11:22PM +0100, Miriam Ruiz wrote:

> In my opinion setuid(0) should not be used for that, as it opens a potential
> security hole which in most of the games is quite real, as they're not really
> usually designed for handling attacks (buffer overflows,  badly handled
> temporary files,...)

  Definitely.

  Mostly games use setgid(games) for this.  Setuid games are mostly
 historical ones which use their root privileges for accessing hardware
 directly.

> It would be nice to develop some guidelines to handle points like that, as
> they're quite common to many games.

  Yes.

> It would be sensible to do something like that, but that makes a different
> highscore list for every user that runs the program. Is this the desired
> behaviour? 

  I'd be tempted to say the gains are worth the change.

> Or do users prefer to have a common highscore list to share with
> other users of the computer? I'm not really sure to have the answer for that.

  I think the question really is how many games are played upon
 shared computers.

  I have a desktop at home where there are two users.  But both of us
 play different games, so highscores are never shared anyway.

> In any case, we should find a way to handle common highscore lists without the
> need for setuid(0). Maybe using some special group and permissions? I have no
> clue.
 
  There is such a group already "games", most games are setgid(games)
 for precisely this reason.  (Perhaps I wasn't clear in my previous
 message.)

> That also happens to some of my packages, as their upstreams consider them as
> totally finished and will not release a new version. That's not really a bad
> thing for a game, as it needn't be continuously growing (at least not every
> kind of game needs), but has the disadvantage that I must do upstream
> maintaining myselg (like porting to gcc4, changes of API in game libraries,...

  Exactly.

> Well, that's the idea I have in mind for the group, like setting up a
> subversion repository and maintaining them in a collaborative way, something
> like KDE team does or so. This has lots of advantages over the one package-one
> developer approach.

   I'm not a huge fan of subversion, or revision control for debian
  packages.  Since mostly the debian/ subdirectory doesn't change much
  and you're essentially importing the new game releases for every
  new upstream release.

   Still if thats what it took .. I guess I'd go for it.

> Anyway, the group is open to individual maintainers who don't want to share
> this metodology but want to join us in discussing many topics related to games
> packaging.

  :)

Steve
--