* Introduce USE_GAMESGROUP, which causes the games user and group to
be made available.
* Retain SETGIDGAME as an alias for USE_GAMESGROUP. Describe it as
deprecated.
* Always define GAMES_USER, GAMES_GROUP, GAMEMODE, GAMEDIRMODE, and
GAMEDATAMODE, regardless of whether USE_GAMESGROUP is turned on or not.
* Define these variables in defaults/mk.conf instead of separately in
every platform/*.mk file. The definitions used to be the same for each
of these platforms anyway, except for some where they were randomly
missing or commented out for no clear reason, leading to broken game
packages.
* Handle all these variables properly when unprivileged.
* Update the comments/documentation for these variables.
* Describe GAMEOWN and GAMEGRP as deprecated. These need to be
retained as aliases for GAMES_USER and GAMES_GROUP respectively for
supporting packages that use bsd.*.mk but should otherwise not be
used.
* Add GAMEDATA_PERMS and GAMEDIR_PERMS using GAMEDATAMODE and
GAMEDIRMODE respectively.
* Fix a bug I noticed that was improperly mixing the "games" group
and "games" user.
Things this does *not* do:
- get rid of GAMES_USER, for which there should ultimately be no need.
- move the declaration/documentation/default value of USE_GAMESGROUP
to a suitable place. (It is currently where SETGIDGAME was, which is
suboptimal.)
- touch any of the games, all of which need updating with at least
s/SETGIDGAME/USE_GAMESGROUP/ and probably more.
- update the guide to explain how to handle games properly.
Also, it would be nice if using GAMES_GROUP without setting
USE_GAMESGROUP=yes caused an error but as far as I know there isn't
any particularly good way to arrange this right now.
Note that these changes may alter the build/install behavior of broken
game packages, e.g. some may silently become setgid when they weren't
before or things like that. If you run into any of this file a PR.
While one might arguably bump the PKGREVISION of all games or other
packages using any of these variables as a precaution, that seems like
a bad idea. Instead, I think I will be bumping each game once it
itself has been fixed up to do everything the right way.
files. These variables are currently usable if ${SETGIDGAME} == yes.
These variables should be used when describing ownership of files
and directories to the pkginstall framework, e.g.
SPECIAL_PERMS= bin/foogame ${GAMES_USER} ${GAMES_GROUP} 2555
+ Rename SETGID_GAME_PERMS to SETGID_GAMES_PERMS because the default
group name is "games".
+ Define SETGID_GAMES_PERMS in terms of GAMES_USER and GAMES_GROUP so
that these names are protected from the normal flow of unprivileged.mk.
This fixes the +INSTALL scripts in "user-destdir" packages to
correctly refer to the games:games instead of the user:group of the
user that built the packages.
(new) UNPRIVILEGED_GROUPS list.
In addition, the value of UNPRIVILEGED_GROUPS is defaulted to all the
groups the installing user is a member of, in a similar mold to
UNPRIVILEGED_GROUP and UNPRIVILEGED_USER.
This allows non-root installations of packages that have special group
requirements but no special user requirements, so long as the installation
user has been given the necessary group membership.
Raised on tech-pkg @ 2007/10/14.
the owner of all installed files is a non-root user. This change
affects most packages that require special users or groups by making
them use the specified unprivileged user and group instead.
(1) Add two new variables PKG_GROUPS_VARS and PKG_USERS_VARS to
unprivileged.mk. These two variables are lists of other bmake
variables that define package-specific users and groups. Packages
that have user-settable variables for users and groups, e.g. apache
and APACHE_{USER,GROUP}, courier-mta and COURIER_{USER,GROUP},
etc., should list these variables in PKG_USERS_VARS and PKG_GROUPS_VARS
so that unprivileged.mk can know to set them to ${UNPRIVILEGED_USER}
and ${UNPRIVILEGED_GROUP}.
(2) Modify packages to use PKG_GROUPS_VARS and PKG_USERS_VARS.
Packages may set PKG_DESTDIR_SUPPORT to either "destdir" or
"user-destdir" to flag support for this, following the same
rules as PKG_INSTALLATION_TYPES (e.g. define before first include
of bsd.prefs.mk).
The user activates it via USE_DESTDIR. When set to "yes",
packages with "user-destdir" are handled as "destdir".
The installation of the package will not go to ${LOCALBASE},
but a subdirectory of ${WRKDIR} instead. pre/post install scripts are
not run and the package is not registered either. A binary package
can be created instead to be installed normally with pkg_add.
For "user-destdir" packages, everything is run as normal user and
ownership is supposed to be correctled by pkg_create later. Since
the current pkg_install code uses pax and it doesn't allow overwriting
owners, this does not work yet.
For "destdir" packages, installation, packaging and cleaning is run as
root.
This commit does not change the handling of DEPENDS_TARGET or
bin-install to allow recursive usage.
