Bug 175434 - Pegasus GID conflict
Pegasus GID conflict
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tog-pegasus (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2005-12-10 07:43 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: 2.5-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 12:35:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-12-10 07:43:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051129 Fedora/1.5-1 Firefox/1.5

Description of problem:
GID 66 is used by Wine on my computer.
Installing pegasus generates a storm of warnings, since the useradd/groupadd fail.

The error is redirected to /dev/null...

Version-Release number of selected component (if applicable):
tog-pegasus-2.5-4

How reproducible:
Always

Steps to Reproduce:
Install tog-pegasus.

Additional info:
Comment 1 Jason Vas Dias 2005-12-15 17:33:31 EST
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.
Comment 2 Rahul Sundaram 2005-12-15 17:58:46 EST
> 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.
Comment 3 Joe Orton 2006-03-07 08:36:16 EST
Another package which needs a proper uid/gid assignment. 
Comment 4 Jason Vas Dias 2006-03-07 11:00:54 EST
There are no problems with tog-pegasus obtaining a userid+gid with the latest
package in Rawhide / FC5t3 - tog-pegasus-2.5-6.1 .

Comment 5 Joe Orton 2006-03-07 11:04:11 EST
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.


Comment 6 Bill Nottingham 2006-03-07 12:35:39 EST
Fixed in 2.5-7. uid 66, gid 65. Added to uidgid as well.
Comment 7 Ivan Gyurdiev 2006-03-07 13:01:53 EST
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).
Comment 8 Jason Vas Dias 2006-03-07 13:06:38 EST
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@redhat.com>   - 2.2.5-8
+- fix creation of userid / gid - the previous fix can fail if
+  gid 65 or uid 66 exists already.
+
Comment 9 Bill Nottingham 2006-03-07 13:50:39 EST
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.
Comment 10 Bill Nottingham 2006-03-07 13:54:43 EST
Oh, and if this is in bind too, *that* needs fixed.
Comment 11 Jason Vas Dias 2006-03-07 14:26:41 EST
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 .  
Comment 12 Bill Nottingham 2006-03-07 14:39:39 EST
(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.

Comment 14 Jason Vas Dias 2006-03-07 15:07:42 EST
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.
Comment 15 Jeremy Katz 2006-03-07 15:19:51 EST
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.
Comment 16 Bill Nottingham 2006-03-07 23:37:16 EST
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.)

Note You need to log in before you can comment on or make changes to this bug.