On Tue, Jun 07, 2016 at 11:31:02AM -0400, Laine Stump wrote: > On 06/07/2016 11:15 AM, Peter Krempa wrote: > > On Tue, Jun 07, 2016 at 15:50:38 +0100, Daniel Berrange wrote: > > > On Tue, Jun 07, 2016 at 08:24:14AM +0200, Peter Krempa wrote: > > > > On Mon, Jun 06, 2016 at 14:25:23 -0500, Roy Keene wrote: > > > > > Patch to libvirt master to avoid failing when a user ID is specified, > > > > > e.g. for <seclabel type='dac'>, that does not map to a user name. > > > > > > > > > > This is useful if you want to run each VM as a separate user and not > > > > > bother creating an /etc/passwd entry for each UID. > > > > For this use case you shall prefix the name with a +. Please refer to > > > > the documentation on seclabels. > > > Empirically that does not currently work: > > > > > > # virsh dumpxml serial | grep --after 2 '<seclabel' > > > <seclabel type='static' model='dac' relabel='no'> > > > <label>+21421:+12421421</label> > > > </seclabel> > > > > > > # virsh start serial > > > error: Failed to start domain serial > > > error: Cannot access storage file '/var/lib/libvirt/images/demo.qcow2' (as uid:21421, gid:12421421): Success > > > > > > # ls -al /var/lib/libvirt/images/demo.qcow2 > > > -rw-r--r--. 1 21421 12421421 197120 Apr 30 2015 /var/lib/libvirt/images/demo.qcow2 > > > > > > > > > Looking at the libvirtd logs we see > > > > > > 2016-06-07 14:49:13.724+0000: 13490: debug : qemuDomainCheckDiskPresence:3954 : Checking for disk presence > > > 2016-06-07 14:49:16.551+0000: 13490: error : virGetUserEnt:801 : Failed to find user record for uid '21421' > > > 2016-06-07 14:49:16.551+0000: 13490: error : virStorageFileGetMetadataRecurse:3114 : Cannot access storage file '/var/lib/libvirt/images/demo.qcow2' (as uid:21421, gid:12421421): Success > > > > > > > > > So even though the QEMU driver has honoured the '+' syntax, some of the > > > things QEMU is calling appears to be trying to resolve the UID back into > > > a user password record and failing. > > Indeed. This is caused by calling virFileAccessibleAs which calls > > virGetGroupList so that it can add all groups for the given UID which is > > very strange. The group list is then set after forking at attempting to > > check file presence. I hate root squashed NFS. > > > > I guess we could just skip reporting the error if we can't get the > > group list in that case and just set the provided numerical UID/GID and > > try it that way. > > Without taking the time to wind through the code - are you saying that we're > attempting to get the grouplist for a different uid while running as root, > then doing a fork/seteuid, and then adding the groups that we learned > pre-fork? > > If that's the case, then I think the same results can be achieved by getting > the grouplist *after* seteuid(). It looks like getgroups() gets the groups > for the current uid, while mgetgroups() gets the groups for a specified > username, so getgroups() would avoid the need for a username. I don't think that's going to work as you have a chicken nand egg scenario. ie getgroups() is just reporting the list of supplementary groups set by a previous call to initgroups(). It is the inigroups call that we need to make and why we're lookiing up the grouplist beforehand. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list