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

[Colin Walters]

On Tue, 2013-07-16 at 17:59 +0100, Richard W.M. Jones wrote:

> 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.

What we're trying to achieve with this is that if I do e.g.
guestmount from two separate shells, only one of them will create the
appliance?

That makes sense.

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

Though there's the usual DoS problem from predicably-named directories
in /{,var/}tmp.  Consider /run/user/$UID/libguestfs-cache/ being a
symbolic link to a randomly named /var/tmp/libguestfs.XXXXXX.

> 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.

qemu *could* export some signaling interface to the effect of "I have
called open() on all file arguments specified on the command line".
That seems like it'd be generally useful.

But ok, so as you said in the followup, the real root issue here is
libvirt calling chown.  It's not clear to me why it does so.  It seems
fine if a user suitably privileged to create VMs can crash them
afterwards by writing to or unlinking the kernel/initramfs.