The 'users' gid: sync, games, and man
Bug #25882 describes a problem with the three users sync, games, and
man. All three currently have their primary group set to 'users',
currently gid 100. The discussion got sidetracked into whether users
should have gid 100 at all (given that that's supposed to be in the
dynamic system range at the moment), but I'd like to avoid that part of
the bug for now and concentrate exclusively on the correct primary
groups for sync, games, and man.
FreeBSD appears not to have this user. All GNU/Linux systems I looked
at (Red Hat, Mandrake, SuSE) set its primary group to root. As far as
I know the only thing sync is ever used for is running /bin/sync, so
its gid probably isn't too important; root or maybe nogroup would do.
FreeBSD gives this its own group. All GNU/Linux systems I looked at
set its primary group to users.
We already have a static games group, and have done for long enough
that there's no mention of it in the base-passwd changelog. Surely
that should be the primary group of the games user, since it's there?
The packages that contain files owned by the games user all have them
owned by the games group as well.
FreeBSD gives this its own group. Red Hat and Mandrake don't have it
in their basic passwd file (but they use a different man
implementation anyway). SuSE use the same man implementation as we do
and give it its own group (although they modify man-db to make it use
group privileges much more than ours does).
man and mandb drop privileges to the uid of the calling user except
when they're performing trusted operations (saving cat pages in system
territory, writing to system databases, etc.). As far as I know they
never create group-writeable files as the man user, but if they did it
would almost certainly be a security hole to have their group set to
users. I'm therefore inclined to create a static group for man and set
that as the man user's primary group. If there are objections to that
then the root group would probably do, since /var/cache/man is setgid
root anyway, but I'd prefer to overload groups as little as possible.
All this will address Ian's initial bug report, although not some other
parts of the discussion.
Comments? Please keep email@example.com in the recipient list as
long as the discussion is relevant to it.
Colin Watson [firstname.lastname@example.org]