|Summary:||Cannot install libvirt-daemon, GID '107' already exists - polkitd is squatting on reserved id|
|Product:||[Fedora] Fedora||Reporter:||Reinout van Schouwen <reinouts>|
|Component:||libvirt||Assignee:||Eric Blake <eblake>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||berrange, cfergeau, clalancette, eblake, itamar, jforbes, jyang, laine, libvirt-maint, mitr, veillard, virt-maint|
|Fixed In Version:||libvirt-0.10.2.5-1.fc18||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-05-29 00:51:46 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Reinout van Schouwen 2013-03-21 22:16:25 UTC
Description of problem: I have a proble installing libvirt-daemon under F18: libvirt-daemon-0.10.2.3-1.fc18.x86_64.rpm | 1.8 MB 00:00:18 Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction groupadd: GID '107' already exists useradd: group 'qemu' does not exist error: %pre(libvirt-daemon-0.10.2.3-1.fc18.x86_64) scriptlet failed, exit status 6 Error in PREIN scriptlet in rpm package libvirt-daemon-0.10.2.3-1.fc18.x86_64 Verifying : libvirt-daemon-0.10.2.3-1.fc18.x86_64 1/1 Failed: libvirt-daemon.x86_64 0:0.10.2.3-1.fc18 Complete! Version-Release number of selected component (if applicable): 0.10.2.3-1.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. yum install libvirt-daemon 2. 3. Actual results: Installation fails with above error Expected results: libvirtd is installed so that I can run gnome-boxes. Additional info: GID 107 is polkitd on my machine. Even after manually adding a qemu group, the PREIN scriptlet complains that UID 107 is not unique. Apparently it insists on creating a user and group with id 107, even if they already exist?
Comment 1 Eric Blake 2013-03-21 22:36:02 UTC
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.
Comment 2 Eric Blake 2013-03-21 22:41:05 UTC
(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.
Comment 3 Miloslav Trmač 2013-03-21 23:02:24 UTC
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.
Comment 4 Miloslav Trmač 2013-03-21 23:32:12 UTC
(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
Comment 5 Christophe Fergeau 2013-03-22 09:05:46 UTC
(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
Comment 6 Daniel Berrange 2013-03-22 10:16:42 UTC
> 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.
Comment 7 Reinout van Schouwen 2013-03-22 10:51:22 UTC
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.
Comment 8 Miloslav Trmač 2013-03-22 17:19:52 UTC
(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.
Comment 9 Miloslav Trmač 2013-03-23 00:09:59 UTC
(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.
Comment 10 Miloslav Trmač 2013-04-29 22:26:26 UTC
FWIW, the FPC has approved updated guidelines, with some comments on behavior of both libvirt and shadow-utils.
Comment 11 Eric Blake 2013-05-01 20:33:41 UTC
Upstream patch proposed; it should be possible to backport to F18 once approved. https://www.redhat.com/archives/libvir-list/2013-May/msg00044.html
Comment 12 Miloslav Trmač 2013-05-02 13:57:16 UTC
Filed #958842 for a possible shadow-utils change.
Comment 13 Eric Blake 2013-05-06 21:15:33 UTC
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 <firstname.lastname@example.org> 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 <email@example.com> (cherry picked from commit a2584d58f6f7d941b960f996c8e26df8294b79b9) Conflicts: libvirt.spec.in - no backport of c8f79c9b %if reindents
Comment 14 Fedora Update System 2013-05-19 23:18:05 UTC
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
Comment 15 Fedora Update System 2013-05-21 08:27:08 UTC
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).
Comment 16 Fedora Update System 2013-05-29 00:51:46 UTC
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.