Hard link to root-owned file now fails (since Fedora 19)

Richard W.M. Jones rjones at redhat.com
Tue Jul 16 16:59:13 UTC 2013


On Tue, Jul 16, 2013 at 05:42:00PM +0100, Richard W.M. Jones wrote:
> On Tue, Jul 16, 2013 at 11:50:10AM -0400, Colin Walters wrote:
> > On Tue, 2013-07-16 at 15:59 +0100, Richard W.M. Jones wrote:
> > >  I'm not even sure
> > > how to do that because we want the atomic behaviour of hard links, and
> > > we want to have qemu running as a different user (for security, oh the
> > > irony), so there's no other obvious way to code it.
> > 
> > Can you link to or describe the relevant algorithm/code?  The file
> > https://github.com/openstack/nova/blob/master/nova/virt/disk/vfs/guestfs.py#L94
> > doesn't contain an obvious call to link().
> 
> Thanks for any input.  It's this code below.  The big comment at the
> top explains roughly what's going on, but misses out a crucial detail:
> If you are using libvirt in a certain way, then libvirtd [which runs
> as root] will chown the 'kernel' and 'initrd' files to root.root.  If
> that chown didn't happen, then none of this would be a problem.
> 
> https://github.com/libguestfs/libguestfs/blob/master/src/appliance.c#L68

I'll just add a bit about how the locking works in this code
since it may not be obvious.

There's a lock (building_lock) which stops two threads from the same
process from entering the appliance building code in parallel.

There's also a lock (fcntl held on the file 'checksums') which stops
two processes owned by the same user from trying to rebuild the
appliance in parallel.

And different users have their own directory ($UID == euid is
different), so those don't interfere.

BUT after we've built the appliance, we have to pass it over (by
reference to the filename) to qemu.  Now qemu runs in its own sweet
time a bit later on, and we can never know when qemu will actually
read these files (and because qemu may run for an indefinitely long
period of time, we can't block other processes here).  That's where
the hard link comes in: it gives qemu effectively its own copy of the
kernel, initrd and root files, while letting us safely erase [the
hard-linked alias] from another process.

These files are huge so copying them isn't an alternative.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v


More information about the devel mailing list