tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

the setgid games mess



Currently handling of games that install setgid (e.g. for access to a
global high scores file) is a big mess.

After wading through this stuff, I've come to the following
conclusions:

   - Because SETGIDGAME is a base-system setting, it should not be
     used by pkgsrc at all. This is especially true since currently
     setting "SETGIDGAME=no" in mk.conf will have the opposite effect
     on /usr/games as intended.

   - It does not make sense for pkgsrc to have a special global
     blanket setting to deny setgid on all games.

   - Games where it makes sense to install either setgid or not setgid
     (e.g. games that still work without setgid) should support a
     package option "setgidgame". Then PKG_DEFAULT_OPTIONS=-setgidgame
     will suppress setgid installation where that makes sense.

   - Games that support the setgidgame option should generally set it
     by default, so we don't generate crippled binary packages.

   - Most games will run in UNPRIVILEGED environments just fine,
     because all they care about is whether they can write to their
     score files. For this reason, the UNPRIVILEGED=yes case should
     do sensible things automatically.

   - Since there are multiple possible ways for a game to install
     itself to run without setgid (in the non-UNPRIVILEGED case), it
     doesn't make sense to try to automate handling for that.

   - (Of those ways the only one we could reasonably handle
     automatically is using a mode 666 scorefile. It's not clear
     we want to support that at all, much less encourage it.)

This leads to the following suggestions for action:

   - Currently we have both GAMES_USER/GAMES_GROUP and GAMEOWN/GAMEGRP
     variables. This duplication seems pointless and GAMEOWN/GAMEGRP
     should go away, except in a couple places involved in supporting
     bsd.*.mk-using packages.

   - GAMES_USER should also probably go away entirely, unless there
     are games that insist on being setuid rather than setgid. I don't
     see any, plus if any appear I'd lean towards patching them rather
     than accomodating them.

   - We already have SETGID_GAMES_PERMS for game executables, which
     should be used with SPECIAL_PERMS like this:

        SPECIAL_PERMS+=bin/mygame ${SETGID_GAMES_PERMS}

   - We should add GAMEDATA_PERMS and GAMEDIR_PERMS variables, and
     game score files should be installed using REQD_FILES_PERMS, like
     this:

        SCOREDIR=${VARBASE}/games/mygame
        SCOREFILE=${SCOREDIR}/scores
        REQD_DIRS_PERMS+=${SCOREDIR} ${GAMEDIR_PERMS}
        REQD_FILES_PERMS+=/dev/null ${SCOREFILE} ${GAMEDATA_PERMS}

   - There should be no explicit flag for setgid games; that is, no
     equivalent of putting "SETGIDGAME=yes" in a package makefile.
     All this stuff should work without it, except perhaps for
     creating the games group. Are groups mentioned in SPECIAL_PERMS
     and so forth automatically added to PKG_GROUPS? If not, then
     perhaps we want a USE_GAMESGROUP=yes setting to do that.

   - In order to make this work, the various platform .mk files should
     be adjusted so that GAMES_GROUP (and GAMES_USER if it doesn't go
     away) is always defined, rather than being randomly commented out
     or randomly conditionalized on SETGIDGAME.

   - GAMEMODE/GAMEDIRMODE/GAMEDATAMODE should not be defined in the
     platform .mk files but in someplace common. They should not be in
     mk/defaults/mk.conf either. Someone please tell me where the
     right place is!

     GAMEMODE should be 2555.
     GAMEDIRMODE should be 775.
     GAMEDATAMODE should be 664.

   - When UNPRIVILEGED=yes, GAMES_GROUP, GAMEMODE, GAMEDIRMODE, and
     GAMEDATAMODE should be adjusted accordingly, to
     UNPRIVILEGED_GROUP, 555, 755, and 644 respectively. This is at
     least partly already in place.

Comments? Things I've forgotten?

I also discovered that REQD_FILES_PERMS is not documented, but
something else nonexistent called SUPPORT_FILES_PERMS is. Someone
might want to update the guide. :-/

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index