[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
> 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)
UNPRIVILEGED (already exists)
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
Main Index |
Thread Index |