Bug 511957

Summary: Allocate a 'qemu' username and groupname
Product: [Fedora] Fedora Reporter: Daniel Berrange <berrange>
Component: setupAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: ovasik, pknirsch, xtv8d
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: setup-2.8.7-1.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-21 08:54:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 498969    

Description Daniel Berrange 2009-07-15 15:32:53 EDT
Description of problem:
A Fedora 12 feature is for libvirt to run the QEMU guests as an unprivileged user account, instead of root:root

  http://fedoraproject.org/wiki/Features/VirtPrivileges

Thus, we need to have a 'qemu' username and groupname allocated.

The 'qemu' username should be a member of the 'qemu' and 'kvm' groups by default.


Version-Release number of selected component (if applicable):
setup-2.8.3-1.fc11.noarch

How reproducible:
N/A

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Ondrej Vasik 2009-07-16 01:57:36 EDT
Ok, the only problem with reservation is that there are no free uid/gid pairs under 100 (some free uids, no free gids). Are you ok with having reserved uid/gid above 100? E.g. 101? I'll modify /etc/profile and similar files to increase threshold for reserved uid/gids so likely no difference for you - but it will be first reserved uidgid above 100 - so some more modifications in some configs may be necessary to make it handled the same way as the rest of reserved system account id's.
Comment 2 Daniel Berrange 2009-07-16 09:01:57 EDT
The potential problem would be a local user account already using the newly allocated ID, but then user accounts don't start until 500 by default, so in theory there's a little space on most systems

In the RPM %post, instead of   'useradd -u 101 qemu', we'd likely have to first check if '101' was already allocated, and if so, fallback to letting useradd pick a random uid ?
Comment 3 Ondrej Vasik 2009-07-16 09:31:06 EDT
Yep, user accounts start above 500 by default - anyway you have to always check for the existence of the uid/gid in the post - even under 100 ... Anyway - I checked (googled) about the existence of uid/gid 101 in Fedora - and it seems that some packages already do use that uid/gid even without reservation in setup uidgid file. Bad luck - the lowest one without presence in google archives was 107.
So I would say this one would be better - as it seems I have to make some cleanup/bugzillas filling to make order in Fedora above uid/gid 100. 

So you should have something like in your %post:
getent group qemu >/dev/null || groupadd -g 107 -r qemu
getent group kvm >/dev/null || groupadd -g 36 -r kvm
getent passwd qemu >/dev/null || \
useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \
-c "qemu user" qemu

This should be ok and sufficient (at least other packages with reserved uidgid in uidgid file just do that) - as it is user's fault to use that reserved id. So I'll reserve 107 uidgid pair in next rawhide setup update if you have no objections.
Comment 4 Daniel Berrange 2009-07-16 09:54:25 EDT
That gets my vote, thanks.
Comment 5 Ondrej Vasik 2009-07-21 08:54:46 EDT
Ok, reserved 107:107 for qemu in setup-2.8.7-1.fc12, closing RAWHIDE.
Comment 6 Nuno 2011-11-10 02:11:19 EST
Small question please, if I have this uid already taken on my system and want to install qemu-kvm can I just manually do:
useradd -r -g qemu -G kvm -d / -s /sbin/nologin -c "qemu user" qemu
before installing qemu-kvm? to create qemu user with a random uid... or will something get broken (i.e. if uid 107 usage is hardcoded somewhere else)?