Bug 253754 – Some ebuilds do not create system groups correctly, instead they're created as normal groups.

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Francesc Zacarias 2009-01-04 18:21:27 UTC]

Some ebuilds that create new system accounts do it correctly, but its corresponding group is created as a normal group instead as a system group. Because of it, uid and gid don't match.
The file /etc/login.defs sets the range for normal and system UID and GID. Definitions are UID_MIN, UID_MAX, SYS_UID_MIN and SYS_UID_MAX (idem for GID).
I've verified this behaviour with packages: sys-apps/dbus-1.2.3-r1 (group messagebus), sys-apps/hal-0.5.11-r4 (haldaemon,plugdev), net-dns/avahi-0.6.24 (avahi,netdev), gnome-base/gdm-2.20.8 (gdm) and app-emulation/kvm-81 (kvm).

Reproducible: Always

Steps to Reproduce:
1. Install any of the packages specified on the description field.
2.
3.

Actual Results:  
Groups for system services are created as normal groups: their assigned GID belong to the normal group range (1000-60000 by default).

Expected Results:  
Groups for system services should honour the settings in /etc/login.defs: SYS_GID_MIN and SYS_GID_MAX (whose default values are: 100-999).

This bug has some implications:
-From now on, no user or system account's uid will match with its gid.
-System groups use the normal group account range, and thus making it shorter than the user account range. (You may have room for new uid but not for gid)
-It's more difficult to tell which groups are user related and which are system related.
-It's plain weird and confusing, Gentoo is the only linux distro I've found to perform like this.
To sum up, this makes user administration more difficult.

Note that not all packages perform like this and some do it right, like net-misc/ntp or net-nds/portmap.

[Comment 1 Francesc Zacarias 2009-01-04 18:29:35 UTC]

Created attachment 177373 [details]
elog for sys-apps/hal installation.

[Comment 2 Francesc Zacarias 2009-01-04 18:30:23 UTC]

Created attachment 177374 [details]
elog for net-misc/ntp.

[Comment 3 Francesc Zacarias 2009-01-04 18:32:21 UTC]

I've attached a couple of elogs. One for an incorrect system group creation (sys-apps/hal) and another for a good one (net-misc/ntp).

[Comment 4 Jeroen Roovers (RETIRED) 2009-01-05 17:59:40 UTC]

QA: Please verify the validity of this bug report. If it's valid, then we should turn this into a tracker bug and open separate bug reports per package.

[Comment 5 SpanKY 2009-01-06 10:22:03 UTC]

ntp has the uid/gid hardcoded which is why you think it "worked".  enewuser adds users between 100 and 1000, but enewgroup does not.

[Comment 6 Francesc Zacarias 2009-01-06 12:59:11 UTC]

(In reply to comment #5)
> ntp has the uid/gid hardcoded which is why you think it "worked".  enewuser
> adds users between 100 and 1000, but enewgroup does not.
> 

Then enewgroup default behaviour should be changed to create system groups by default, shouldn't it? Is there a reason for an ebuild to create normal user/group accounts? Specially when enewuser already creates system user accounts.

Also, it's a problem that some ebuilds have the UID/GID hardcoded. Either ALL should be hardcoded or NONE. Mixing hardcoded and sequential can create "collisions". What if I install 124 services (with their respective sequential system accounts) and then I emerge ntp (which has GID 123 hardcoded)?
Is there a reason for some uid/gid pairs to be hardcoded?

[Comment 7 SpanKY 2009-01-06 14:09:48 UTC]

i was only commenting on current enewgroup behavior.  it probably should be changed as you suggest.

as for your other comments, no, nothing is going to change today with how UIDs are managed.  everything is being done with Bug 53269 (which more than covers everything you've said).

[Comment 8 Francesc Zacarias 2009-01-06 16:23:04 UTC]

(In reply to comment #7)
> i was only commenting on current enewgroup behavior.  it probably should be
> changed as you suggest.
> 
> as for your other comments, no, nothing is going to change today with how UIDs
> are managed.  everything is being done with Bug 53269 (which more than covers
> everything you've said).
> 

Thanks for pointing that interesting bug link. I may ask a few questions there.

[Comment 9 Francesc Zacarias 2009-01-06 16:52:06 UTC]

BTW, I've found this:
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/uidrange.html
Notice that it says nothing on GIDs, but it's expected that the same rules apply. Or at least, that's how other linux distros do it.

[Comment 10 SpanKY 2009-01-07 11:09:46 UTC]

we dont particularly care about LSB.  it's an indicator show how some other people might approach the issue, but we do not force anything in Gentoo to follow it in any way.

[Comment 11 Mark Loeser (RETIRED) 2009-06-28 02:27:56 UTC]

Seems letting this discussion happen in bug #53269 is better

*** This bug has been marked as a duplicate of bug 53269 ***