tech-pkg archive

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

Re: SETGIDGAME in package's Makefile. Why?



On Fri, 26 Dec 2008 16:57:39 +0900, David Holland 
<dholland-pkgtech%netbsd.org@localhost> wrote:

> Yes, it is all broke, and has been for a long time. There are also
> various other related problems, e.g. some games use the config file
> mechanism to install their high scores.

Why do you think that high score files should not be cared with CONF_FILES?
How to take care instead?

> Most games with high scores files care only if the high scores are
> writeable, and will work fine if installed unpriv'd but need to be
> setgid if using a root-owned $(VARBASE).

Should we handle the situation, unpriv'd package with root-owned $(VARBASE)?
It is not only for games.

> IME, most of these games also do not fall back cleanly to per-user
> scorefiles or whatever if they can't write in $(VARBASE), so unless
> built unpriv'd they should be installed setgid by default.
>
> For games where it does make sense to install either setgid or not,
> the choice should probably be made via a package option. "SETGIDGAME"
> should go away. Not only is it widely misused, it's also too broad a
> switch, and it's misspelled - as a global config option it should have
> been "SETGIDGAMES".
>
> (In most cases I think the setgid option should default to yes, that
> is, setgid. While it's not necessarily desirable to install setugid
> binaries by default, it's also not desirable to create crippled binary
> packages. Plus it's quite a bit easier to chmod -s after installing
> than to go track down what might want a chmod g+s.)
>
> Fixing all this is a big pile of work though.

IMO...introduce following variable to refrect those situations...

Package variable USE_SETGIDGAMES (new variable)
  requre        need SETGIDGAMES=yes, or failed to work
  yes           if SETGIDGAMES=no, some features not work(ex. high score will 
not be saved)
  no(default)   no impact on SETGIDGAMES .

User variable SETGIDGAMES (already exists)
  yes
  no

UNPRIVILEGED (already exists)
  yes
  no

Only one situation, USE_SETGIDGAES=requre/SETGIDGAMES=no/UNPRIVILEGED=no,
I can't define suitable behaviour.

-- 
"Of course I love NetBSD":-)
OBATA Akio / obache%NetBSD.org@localhost


Home | Main Index | Thread Index | Old Index