Handling of new user/group additions from binary packages is broken
w.r.t. the file ownerships given within binary archives, and it is
effectively broken in its design.
Currently it is inevitable that user and group names will end up with
different uid/gid values on target install systems, i.e. production
systems which are not "pristine" (just freshly installed), and where the
package does not specify explicit uid/gid values (and if it does then
uid/gid conflicts are likely).
The problem is that the binary archive file is fully extracted _before_
the username/groupname is created thus even though it contains both the
username and the uid (groupname and the gid) only the uid/gid numeric
values can ever be used. If the id number given in the archive is
already in use on the target system for an unrelated user then the file
will end up being owned by the existing group or user, then the expected
user and/or group will be created, but with a new uid/gid, and the file
will not have its ownership updated to match the new username/groupname.
Partly this is further exacerbated (i.e. made more likely) by the fact
that there is no way within pkgsrc to reserve a range of id numbers
explicitly for the use of packages (i.e. make use of the
useradd/groupadd '-r' option) -- ordinary user accounts will be created
by the local admin in the same range as accounts for packages will be
created on the build system. The build system, being what it is, will
not usually have the same local user accounts as production systems, and
may not even be operated by the same organization.
Previously I've mostly worked around it by carefully testing each
package build by hand and then ensuring all necessary users and groups
are manually (pre)installed on all my systems for all the packages I
normally build. However I'm now upgrading packages often enough on
production systems where it is not easy to continue to always manually
pre-add all the new package-specific users and groups needed. To some
extent I've been able to modify package modules to use specific UID/GID
values that I'm reasonably certain will be outside the range of normal
local users on all the systems I build packages for, but this doesn't
always work, especially when I miss checking some dependent package
which requires a new user and/or group.
The ideal solution would be to _never_ rely on the ownerships in the
binary package archive files and instead use the PLIST file exclusively
to set ownerships of all files (which need non-standard ownerships (and
permissions too?)) via a generated MTREE file (and I think this was the
intent of MTREE files in the original pkg_install design), but of course
that would likely require far more maintenance overhead for package
modules, at least for those which do require special users and/or
groups.
The hack would be to extract just the package meta files first, then run
the require(YES!) and pre-install scripts (thus creating any necessary
users and groups with appropriate conflict checking), _then_ finally
extract the rest of the archive thus allowing pax to change the
ownership of extracted files to match the owner IDs on the target
system. This breaks though if the package has internal knowledge of any
uid/gid numbers (even though that should be a bug by definition).
In any case though it would be _extremely_ valuable to make use of the
useradd/groupadd '-r' options (where available), and to make sure to do
so on the _target_ system too, not just the build system! I don't know
what to do about systems which do not support such a feature, but which
do have otherwise sufficient and/or necessary platform specific
useradd/groupadd tools. (In my local changes to a much earlier version
of pkgsrc I had some hacks to use '-r' on the build system, but they
weren't designed properly for binary packages either -- they avoided the
issues only by accident, not by design.)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgp8nnHNiRJXh.pgp
Description: PGP signature