Bug 924501

I'm trying to determine if there is a canonical registry of reserved uids in Fedora; if there is, and libvirt owns 107 in that registry, then this bug should be reassigned to polkitd, and you should determine why polkitd is squatting on a uid that it has not reserved.

(In reply to comment #1)
> I'm trying to determine if there is a canonical registry of reserved uids in
> Fedora; if there is, and libvirt owns 107 in that registry, then this bug
> should be reassigned to polkitd, and you should determine why polkitd is
> squatting on a uid that it has not reserved.

Looks like the canonical list is in /usr/share/doc/setup-*/uidgid, and that clearly lists 'qemu' as user 107.  Reassigning to polkit.

polkit does simply
> getent group polkitd >/dev/null || groupadd -r polkitd
> getent passwd polkitd >/dev/null || useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd

At least since http://fedoraproject.org/wiki/Features/1000SystemAccounts (Fedora 16), dynamically-assigned ID numbers are assigned highest-to-lowest.  That's what happens on my machine (fresh F18 installation):

> $ getent passwd polkitd
> polkitd:x:999:999:User for polkitd:/:/sbin/nologin


Reinout, how was your system installed? Is it an upgrade from an earlier version?  Can you attach your /etc/login.defs, please?


Eric, you're right that libvirt "owns" 107, however there's not a strong guarantee that 107 is free (especially if a centralized LDAP system is used to manage the system UIDs - we keep adding UIDs so conflicts can arise from time to time).  What I've suggested in the past is in bug #699713 comment 19 (and 20), I'll finally propose this to FPC.

(In reply to comment #3)
> Eric, you're right that libvirt "owns" 107, however there's not a strong
> guarantee that 107 is free (especially if a centralized LDAP system is used
> to manage the system UIDs - we keep adding UIDs so conflicts can arise from
> time to time).  What I've suggested in the past is in bug #699713 comment 19
> (and 20), I'll finally propose this to FPC.

For the record: https://fedorahosted.org/fpc/ticket/269

(In reply to comment #3)
> Reinout, how was your system installed? Is it an upgrade from an earlier
> version?

23:25 < teuf> reinouts: libvirt.spec says 107:107 is reserved for qemu
23:30 < reinouts> teuf, I believe you, but this is how my system is configured
                  (f16 upgraded via f17 to f18 now)
23:30 < reinouts> and I certainly didn't fiddle with such low-level settings

> Eric, you're right that libvirt "owns" 107, however there's not a strong
> guarantee that 107 is free (especially if a centralized LDAP system is used
> to manage the system UIDs - we keep adding UIDs so conflicts can arise from
> time to time).  What I've suggested in the past is in bug #699713 comment 19
> (and 20), I'll finally propose this to FPC.

If polkit needs a system uid:gid pair, then file a BZ against the 'setup' package requesting one to be assigned. You cannot just grab any free uid:gid pair and expect things to work fine. Administrators of LDAP have to look at the standard uid:gid map and ensure they don't clash with Fedora reserved ids.

Created attachment 714479 [details]
/etc/login.defs as requested

As I said to teuf on irc, my machine was installed with F16 and upgraded to F17 and F18 subsequently.

(In reply to comment #6)
> > Eric, you're right that libvirt "owns" 107, however there's not a strong
> > guarantee that 107 is free (especially if a centralized LDAP system is used
> > to manage the system UIDs - we keep adding UIDs so conflicts can arise from
> > time to time).  What I've suggested in the past is in bug #699713 comment 19
> > (and 20), I'll finally propose this to FPC.
> 
> If polkit needs a system uid:gid pair, then file a BZ against the 'setup'
> package requesting one to be assigned. You cannot just grab any free uid:gid
> pair and expect things to work fine.

polkit isn't grabbing any ID, it's letting useradd/groupadd choose one from a supposedly non-conflicting namespace, as described in comment #3.  Actually it's polkit that follows https://fedoraproject.org/wiki/Packaging:UsersAndGroups and libvirt that doesn't (but I'm trying to get the guidelines amended, see above.)

> Administrators of LDAP have to look at
> the standard uid:gid map and ensure they don't clash with Fedora reserved
> ids.

That works only if it is not necessary to also manage non-Fedora systems by the same LDAP server, and only until a new Fedora release comes out with more Fedora-reserved IDs.

(In reply to comment #7)
> Created attachment 714479 [details]
> /etc/login.defs as requested
> 
> As I said to teuf on irc, my machine was installed with F16 and upgraded to
> F17 and F18 subsequently.

Thanks, I have reproduced the problem.


On a clean F16 or later installation, the configuration is:
> UID_MIN                  1000
> UID_MAX                 60000
> SYS_UID_MIN               201
> SYS_UID_MAX               999
> GID_MIN                  1000
> GID_MAX                 60000
> SYS_GID_MIN               201
> SYS_GID_MAX               999

whereas your configuration is:
> UID_MIN                   500
> UID_MAX                 60000
> GID_MIN                   500
> GID_MAX                 60000
which defaults SYS_[UG]ID_MIN to 101.

Now, even in this case groupadd -r will allocate dynamic ID values top to bottom; the catch is that it first looks for GID
> $best_gid = (min (all allocated GIDs in range [SYS_GID_MIN, SYS_GID_MAX])) -1
i.e. if there are any "holes" in the GID allocatio within the SYS_GID_* range, they are not filled unless absolutely necessary.

So, something like the following can happen:
* install jetty - uses a statically allocated GID 110
* install ovirt - uses a dynamically allocated GID.
  On a default installation, this would be somewhere in the 990s;
  With the attached configuration, 110 is included in the SYS_GID_* range, so
  $best_gid == 109, => allocates GID 109 for group "ovirt"
* one more installation similarly allocates GID 108
* on update from F17 to F18, update of polkit adds the "polkitd" group with GID 107.


Given that https://fedoraproject.org/wiki/Packaging:UsersAndGroups currently mandates using dynamic allocation, and an ordinary developer desktop on F18 has more than 10 such dynamically allocated GIDs, I don't think it's realistic to ask that all of the packages that use dynamic allocation should be changed - especially because such change would only help libvirt if all of these packages where modified to _change_ the GID allocation to a new static one even on existing installations.


Perhaps useradd/groupadd should prefer filling the "holes" first.  However that would still not make any existing installation work, nor would it avoid ID allocation conflicts with pre-existing LDAP setups.


So, back to libvirt - libvirt can either decide that the attached login.defs configuration is invalid (because it doesn't follow the allocation at http://fedoraproject.org/wiki/Features/1000SystemAccounts), or modify its scripts to use a different GID if the one allocated to libvirt is already taken, as suggested in https://fedorahosted.org/fpc/ticket/269 .  Considering that similar problems can arise in LDAP environments, the second option is preferable IMHO.

At this time I think it would be best to wait for the FPC discussion, they might ask for changes of the "semi-static allocation" script.

FWIW, the FPC has approved updated guidelines, with some comments on behavior of both libvirt and shadow-utils.

Upstream patch proposed; it should be possible to backport to F18 once approved.
https://www.redhat.com/archives/libvir-list/2013-May/msg00044.html

Filed #958842 for a possible shadow-utils change.

The next build of libvirt on the v0.10.2-maint branch will pick up this commit; hence moving this BZ to POST.

commit fd00ec8f920fc3e2516cca578b4e75170da4dd76
Author: Eric Blake <eblake>
Date:   Wed May 1 14:28:43 2013 -0600

    spec: proper soft static allocation of qemu uid
    
    https://bugzilla.redhat.com/show_bug.cgi?id=924501 tracks a
    problem that occurs if uid 107 is already in use at the time
    libvirt is first installed.  In response that problem, Fedora
    packaging guidelines were recently updated.  This fixes the
    spec file to comply with the new guidelines:
    https://fedoraproject.org/wiki/Packaging:UsersAndGroups
    
    * libvirt.spec.in (daemon): Follow updated Fedora guidelines.
    
    Signed-off-by: Eric Blake <eblake>
    (cherry picked from commit a2584d58f6f7d941b960f996c8e26df8294b79b9)
    
    Conflicts:
    	libvirt.spec.in - no backport of c8f79c9b %if reindents

libvirt-0.10.2.5-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libvirt-0.10.2.5-1.fc18

Package libvirt-0.10.2.5-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-0.10.2.5-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8681/libvirt-0.10.2.5-1.fc18
then log in and leave karma (feedback).

libvirt-0.10.2.5-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.