mariner:~> perl -e 'print join "|", getpwnam "Debian-exim"'; echo
Debian-exim|x|100|102||||/var/spool/exim4|/bin/false
mariner:~> perl -e 'print join "|", getgrnam "Debian-exim"'; echo
Debian-exim|x|102|
mariner:~> grep Debian-exim /etc/passwd /etc/group
/etc/passwd:Debian-exim:x:100:102::/var/spool/exim4:/bin/false
/etc/group:Debian-exim:x:102:
mariner:~>
It would be slightly less confusing if the ids matched.
This machine was installed from an etch netinst CD about three weeks
ago and I have configured exim only via dpkg-reconfigure. I'm pretty
sure the user was created by this line in exim4-config's postinst:
adduser --system --group --quiet --home /var/spool/exim4 \
--no-create-home --disabled-login --force-badname Debian-exim
Ian.
This one time, at band camp, Ian Jackskon said: What's the benefit? The reason they don't match is that there are some groups in the 'system gid' range assigned that don't have matching users - specifically, the groups crontab and users. These use 100 and 101 on most systems, so system users that come after can either have their uid's renumbered up to match, or we can take the course adduser currently does and just not worry about something that's not an issue in practice. I guess I do see the aesthetic appeal, but I'm not sure I want to rule out use of some parts of the already fairly small system range, just because either the uid or the gid is already taken. If you can provide a reason that's more than aesthetic, I'm willing to consider it. Take care,
Stephen Gran writes ("Re: [Adduser-devel] Bug#453086: adduser --system --group should ensure uid==gid"):
It doesn't cause any trouble for the computers. But uid==gid is much
easier for humans - it makes life less error-prone because you only
have to remember one id which applies everywhere. It's already the
case for non-system users.
I thought about the problem of exhaustion, but I think in practice
this change wouldn't cause that to be more likely.
On any particular system, either allocation of users or groups will
dominate. And these uids and gids are each allocated sequentially.
So the set of used uids will be a subset of the set of used gids, or
vice versa.
Regards,
Ian.
I never used the numeric values in daily work. I always use the groupnames and usernames. Jörg
Hello, While "playing" with BTS #493988, I discover the following comportement of adduser : If you got foogroup with gid > 1000 # adduser --system --group foogroup Doesn't enforce/warn/exit that foogroup isn't in the system GID range. This doesn't seems in par with the documentation. The documentation also indicates that GID should be the same as UID, from adduser(1) : "...By default, system users are placed in the nogroup group. To place the new system user in an already existing group, use the --gid or --ingroup options. To place the new system user in a new group with the same ID, use the --group option...
Hi, It seems that nothing is moving about this bug that is imho currently misclassified as a wishlist. The documentation of "man adduser" still clearly says what Fab pasted: "--group When combined with --system, a group with the same name and ID as the system user is created." For me it seems like a real problem if the program doesn't follow it's own documentation. So this is a bug. To overcome the UID/GID exhaustion problem the behavior could be like this: - use same UID=GID where there is still room in the system ID range (cross-section of IDs for SYSTEM_UID and SYSTEM_GID) - else fall back to current behavior (assign first free UID and GID) This way the amount of usable system UIDs and GIDs will remain the same and additionally it would be more compliant with the documentation and would look nicer. gw
* GW <gwSPAM.debian@tnode.com>, 2010-05-02 05:19: The attached patch fixes documentation inconsistency.
I have committed this to svn, which improves the situation, while the real issue remains open. Greetings Marc
I have committed this to svn, which improves the situation, while the real issue remains open. Greetings Marc