Bug 175434

OK, I'll change the uid/gid to 466 - I hope nothing else uses 466 -
I have a Rawhide "everything" install and nothing else uses it -
but then nothing used 66 either on my installation.

It would be great if there was a list somewhere of all uids / gids
used by all packages.

Can anyone think of a conflict with 466 ? 

The uid/gid will NOT be changed during an upgrade - only during a 
clean install .

I guess I should put in some logic like:
if ! id pegasus >/dev/null 2>&1; then
  for((uid=466; uid<500; uid++))
  do
     if /usr/sbin/groupadd pegasus -g $uid >/dev/null 2>&1 &&
        /usr/sbin/useradd -u $uid \
                          -c  "tog-pegasus OpenPegasus WBEM/CIM services" \
                          -g pegasus -s /sbin/nologin \
                          -r -d /var/lib/Pegasus pegasus >/dev/null 2>&1; then
        break;
     else
        if egrep -q '^pegasus:.*:'$uid':' /etc/group; then
           groupdel pegasus >/dev/null 2>&1;
        fi;
        if [ $uid -eq 499 ]; then
           uid=100;
        elif [ $uid -eq 465 ]; then
           break;
        fi;
    fi;
  done
fi;

I'm giving the above a try with tog-pegasus-2.5-5 in Rawhide.

> It would be great if there was a list somewhere of all uids / gids
> used by all packages.
> 

For extras, there is a package user registry

http://fedoraproject.org/wiki/PackageUserRegistry

Some of them get a UID assigned using 

http://fedoraproject.org/wiki/fedora-rpmdevtools. There has been discussions
about this on the fedora-packaging list without consensus yet on the right
approach between the above two or any other mechanism.

A equivalent list on Fedora Core packages useful. If you are interested, use the
wiki for that.

Another package which needs a proper uid/gid assignment. 

There are no problems with tog-pegasus obtaining a userid+gid with the latest
package in Rawhide / FC5t3 - tog-pegasus-2.5-6.1 .

There certainly are problems, doing a *search* for an available uid in a %pre

      for((uid=466; uid<500; uid++))
...

is just nasty.  Bill can assign you a fixed <500 uid/gid which will guarantee
there are no conflicts with other packages in the system.

Fixed in 2.5-7. uid 66, gid 65. Added to uidgid as well.

I don't know if this is relevant anymore, but the original bug was filed when
wine still was not in Fedora Extras. I'm not sure how wine gid 66 managed to get
into my group file, but there's 2 ways it could have happened - either through a
CVS install, or through install of the rpm package on winehq.org [ more likely ].

Nowdays I don't see any wine group being used by the wine rpms shipped by
Fedora, so I don't know if gid=66 should still be considered a problem (I
haven't verified if Wine CVS or the winehq rpms still use this gid).

This is now fixed with 2.5-8 - the previous fix can still fail if gid 66 
exists before pegasus is installed, as with BIND bug 181730, when BIND 
used the same method. I've implemented the same fix for tog-pegasus as
I did for bind:

--- tog-pegasus.spec.~1.20.~    2006-03-07 12:40:13.000000000 -0500
+++ tog-pegasus.spec    2006-03-07 13:02:53.000000000 -0500
@@ -18 +18 @@
-Release:       7
+Release:       8
@@ -207,3 +207,13 @@
-   /usr/sbin/groupadd pegasus -g 65 >/dev/null 2>&1 || :;
-   /usr/sbin/useradd -u 66 -c "tog-pegasus OpenPegasus WBEM/CIM services" -g
pegasus \
-        -s /sbin/nologin -r -d /var/lib/Pegasus pegasus >/dev/null 2>&1 || :;
+   # create pegasus group IFF it does not already exist
+   # - use any free ID between 1 and 499 if group 65 exists:
+   /usr/sbin/groupadd -g 65 -f -r pegasus >/dev/null 2>&1 || :;
+   if ! /usr/bin/id -u pegasus > /dev/null 2>&1; then
+      if ! /bin/egrep -q '^[^:]+:[^:]+:66:' /etc/passwd >/dev/null 2>&1 ; then
+         /usr/sbin/useradd -u 66 -r -n -M -g pegasus -s /sbin/nologin -d
/var/lib/Pegasus \
+                          -c "tog-pegasus OpenPegasus WBEM/CIM services"
pegasus >/dev/null 2>&1 || :;
+      else
+         # use any free ID between 1 and 499:
+         /usr/sbin/useradd -r -n -M -g pegasus -s /sbin/nologin -d
/var/lib/Pegasus \
+                          -c "tog-pegasus OpenPegasus WBEM/CIM services"
pegasus >/dev/null 2>&1 || :;
+      fi;
+   fi;
@@ -241,0 +252,4 @@
+* Tue Mar 07 2006 Jason Vas Dias <jvdias>   - 2.2.5-8
+- fix creation of userid / gid - the previous fix can fail if
+  gid 65 or uid 66 exists already.
+

That is completely incorrect. If the gid exists, it uses the already existing
gid correctly. If the GID is taken, that is *sysadmin error*. We have an
assigned range of userids, and we use that.

WE DO NOT RANDOMLY ASSIGN USERIDS. This is RPM 101.

2.5-8 will be reverted and fixed.

Oh, and if this is in bind too, *that* needs fixed.

RE: > If the gid exists, it uses the already existing gid correctly.

This is not the case.  With BIND bug 181730, a group with an ID other than
named had GID 25 .  Then the groupadd failed, and then the useradd failed
because there was no 'named' group.

RE:  > If the GID is taken, that is *sysadmin error*. We have an
     > assigned range of userids, and we use that.
     > WE DO NOT RANDOMLY ASSIGN USERIDS. This is RPM 101.

Yes, we should try to use assigned uids / gids ; but there is currently 
nothing that enforces this policy.  

If sysadmins decide to use GID 25 or GID 66 for something else, are we
really saying that they cannot install or run the BIND or tog-pegasus
packages ? This does not make any sense to me.

Using the '-f' option to groupadd makes it ensure that a group with the given
name definitely either exists or will be created; using the '-r' option makes
groupadd use an unallocated GID between 1 and 499, if the GID specified by
the '-g' option is already allocated.

If a user with the allocated UID already exists, giving then useradd will
fail to add the user (unfortunatley, it does not have an equivalent to
groupadd's '-f' option).

Similarly, this bug was originally raised because someone had installed WINE
and then tried to install pegasus ; gid and uid 66 existed already, so no
pegasus user was created. 

The method in the patch above ensures that a pegasus user and group MUST exist
after first installation of the RPM, even if the allocated UID/GID 66/65 are
already allocated - I cannot see any harm in ensuring this, especially as 
remote access to the cimserver will be denied if that user does not exist.
For bind, it is even worse, since if the named user does not exist, no
bind RPM can be installed and named will not run.  

So, please leave the tog-pegasus and bind user and group creation code as is -
else I'll have to fix it back - thanks .  

(In reply to comment #11)
> RE: > If the gid exists, it uses the already existing gid correctly.
> 
> This is not the case.  With BIND bug 181730, a group with an ID other than
> named had GID 25 .  Then the groupadd failed, and then the useradd failed
> because there was no 'named' group.

Then that is a *locally broken system*. Period. 1-100 are reserved for system
installation of packages. Note that the -f will make it work around
this in any case.

> RE:  > If the GID is taken, that is *sysadmin error*. We have an
>      > assigned range of userids, and we use that.
>      > WE DO NOT RANDOMLY ASSIGN USERIDS. This is RPM 101.
> 
> Yes, we should try to use assigned uids / gids ; but there is currently 
> nothing that enforces this policy.  

There is. We have a stock policy of assigned UIDs. If this package was
packaged correctly *in the first place*, we never would have gotten to
this point.

> If sysadmins decide to use GID 25 or GID 66 for something else, are we
> really saying that they cannot install or run the BIND or tog-pegasus
> packages ? This does not make any sense to me.

*Sigh*. 1-100 have been reserved for system level *installed by the OS* UIDs
for OVER TEN YEARS now.

> Similarly, this bug was originally raised because someone had installed WINE
> and then tried to install pegasus ; gid and uid 66 existed already, so no
> pegasus user was created. 

That's because pegasus was mispackaged *to begin with*. There is a registry
of uids and gids. The original package was using one that was already
assigned.

> So, please leave the tog-pegasus and bind user and group creation code as is -
> else I'll have to fix it back - thanks .  

No. We have packaging standards. Follow them.

The change you suggest is identical to the tog-pegasus user & group creation 
code BEFORE this bug was raised - ie. exactly the same method used by bind:

From tog-pegasus-2.5-4.1 .spec :
#  first install: create the 'pegasus' user and group:
#  By default, ONLY the "pegasus" user will be allowed to connect to cimserver
over network
   /usr/sbin/groupadd pegasus -g 66 >/dev/null 2>&1 || :;
   /usr/sbin/useradd -u 66 -c "tog-pegasus OpenPegasus WBEM/CIM services" -g
pegasus \
                     -s /sbin/nologin -r -d /var/lib/Pegasus pegasus >/dev/null
2>&1 || :;


From bind-9.3.2-5 spec:
/usr/sbin/groupadd -g 25 named >/dev/null 2>&1 || :;
/usr/sbin/useradd -c "Named" -u 25 -g named \
	-s /sbin/nologin -r -d /var/named named >/dev/null 2>&1 || :;

So I fail to see how either tog-pegasus or bind were "mis-packaged" in this
respect.

The problem with this method of userid and group creation, is that if 
at the time the rpm is first installed, a group exists with the allocated 
groupid (named:25 pegasus:66), but with a different name, then no 
named/pegasus user or group is created, and in the case of bind, the
whole RPM install fails, and in the case of pegasus, users cannot connect
to the cimserver over the network.

That problem led to this bug, and bind bug 181730 being raised.

Using '-f' on the groupadd allows the package to be installed correctly,
as the group is created with a different system gid between 1 and 499 
(unfortunately, using the '-K GID_MIN=1 -K GID_MAX=100' option does not
work correctly - '-r' overrides it.

Similarly, for the useradd, if a user with the expected uid already exists,
using '-r' without '-u' allows a new system userid to be created.

We cannot fix this bug nor bind bug 181730 without allowing the packages to
be installed with a pre-existing user and group with the allocated userid and 
gid, which reverting to the method used by tog-pegasus-2.5-4.1 or bind-9.3.2-5
does not do - so I won't be reverting to that method in new tog-pegasus or bind
versions.

You're missing the point.

GID 25 is *RESERVED* for the bind group.  UIDs between 1 and 100 are reserved
for use by system distributors, aka, us.  If someone is in a case where gid 25
is being used by something else, then either
1) They have a package installed which is broken.  Likely because it was playing
games like this to try to grab a gid at random instead of getting one properly
assigned
2) They have manually gone in and used the range which is reserved.

We could just as well be shipping an /etc/passwd and /etc/group file in the
setup package which defines the static uid/gid assignments in the uidgid file
except that it causes difficult problems on upgrade just because you don't want
to be replacing someone's /etc/passwd and making them lose their users and
passwords.  To work around that, packages are instead *REQUIRED* to do
useradd/groupadd in %pre and follow their allocation in uidgid.

This is the way things have worked virtually forever.  Please actually follow
our packaging conventions instead of inventing your own.  Everything you're
trying to use as justification is actually caused by people inventing their own
package policy and is not a problem when the policy is followed.

And the reason it failed *originally* with pegasus is because it was using gid
66. Which is reserved for wine (legacy, but the reservation is there.)