The libvirt sanlock plugin is intentionally leaking a file
descriptor to QEMU. To enable QEMU to use this FD under
SELinux, it must be labelled correctly. We dont want to use
the svirt_image_t for this, since QEMU must not be allowed
to actually use the FD. So instead we label it with svirt_t
using virSecurityManagerSetProcessFDLabel

* src/locking/domain_lock.c, src/locking/domain_lock.h,
  src/locking/lock_driver.h, src/locking/lock_driver_nop.c,
  src/locking/lock_driver_sanlock.c, src/locking/lock_manager.c,
  src/locking/lock_manager.h: Optionally pass an FD back to
  the hypervisor for security driver labelling
* src/qemu/qemu_process.c: label the lock manager plugin
  FD with the process label

When virLockDriverAcquire is invoked during hotplug the state
parameter will be left as NULL.

* src/locking/lock_driver_nop.c,
  src/locking/lock_driver_sanlock.c: Don't reference NULL state
  parameter

In between fork and exec, a connection to sanlock is acquired
and the socket file descriptor is intionally leaked to the
child process. sanlock watches this FD for POLL_HANGUP to
detect when QEMU has exited. We don't want a rogus/compromised
QEMU from issuing sanlock RPC calls on the leaked FD though,
since that could be used to DOS other guests. By calling
sanlock_restrict() on the socket before exec() we can lock
it down.

* configure.ac: Check for sanlock_restrict API
* src/locking/domain_lock.c: Restrict lock acquired in
  process startup phase
* src/locking/lock_driver.h: Add VIR_LOCK_MANAGER_ACQUIRE_RESTRICT
* src/locking/lock_driver_sanlock.c: Add call to sanlock_restrict
  when requested by VIR_LOCK_MANAGER_ACQUIRE_RESTRICT flag

Sanlock is a project that implements a disk-paxos locking
algorithm. This is suitable for cluster deployments with
shared storage.

* src/Makefile.am: Add dlopen plugin for sanlock
* src/locking/lock_driver_sanlock.c: Sanlock driver
* configure.ac: Check for sanlock
* libvirt.spec.in: Add a libvirt-lock-sanlock RPM