Ruby ships its own config.h which may or may not define the same
relevant constants as our autoconf-generated config.h. Instead of
trying to specify the exact path to the wanted header file we may just
as well simply use Ruby's autoconf-inspired checks and macros.
This creates an abstract layer below the protocol code which handles
the socket operations. This will make it easier to introduce libvirt
virSocketPtr operations in future.
In the handle, g->conn contains the connection to the appliance.
g->conn is NULL when we're not connected.
poll(2) is used instead of select(2).
All error messages about launch failing or the appliance unexpectedly
dying are handled by two common error message functions, and these
contain a better explanation of what to do.
The earlier (pipe-based) code never set this flag, but that was a bug,
potentially allowing the file descriptor to be leaked to subprocesses.
Set the FD_CLOEXEC flag, but also ensure it is cleared in the child
process just before qemu is exec'd (otherwise qemu would not have a
console).
The libvirt backend already uses a Unix socket for the appliance
console, and so for the libvirt backend the fields g->fd[0] == g->fd[1].
Change the appliance backend to use a socketpair, so we need just a
single file descriptor for qemu stdin/stdout (ie. appliance console).
Consequently we can remove the array int fd[2] in the handle and
replace it with a single file descriptor.
When debugging is enabled, this prints out the permissions (ie.
ls -laZ) of the appliance and sockets directories. This should be
helpful for debugging RHBZ#913774.
Since qemu connects to both, there was no point at all in having these
sockets be readable by other, nor executable by anyone.
The sockets should now end up as:
srw-rw---- root.qemu
Despite what the documentation may have said, it certainly was not
safe to call guestfs_umount_local from another thread.
guestfs_umount_local could generate events, call the error handler, or
access other fields in the handle, with no locking at all.
We should aim to make guestfs_umount_local thread-safe in future.
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=917706
This function is now generated, so bindings in various languages
are made automatically.
Note that the function previously returned void, but now it returns
int (although always 0). We don't believe that this is an ABI break
since existing programs will continue to work.
Non-daemon functions normally have a wrapper function called
eg. guestfs_name. The "real" (ie. hand-written) function is called
eg. guestfs__name. The wrapper deals with checking parameters and
doing trace messages.
This commit allows the wrapper function to be omitted. The reason is
so that we can handle a few functions that have to be thread-safe
(currently just: guestfs_user_cancel). The wrapper is not thread safe
because it can call events and/or the error handler.
libxml2 xmlXPathEvalExpression can return an unusual nodeset:
$1 = {type = XPATH_NODESET, nodesetval = 0x0, boolval = 0, floatval = 0,
stringval = 0x0, user = 0x0, index = 0, user2 = 0x0, index2 = 0}
Note that the nodeset is non-NULL, but the nodesetval is NULL.
Check every call site and fix those that don't deal with this
correctly.
When adding a domain (ie. guestfs_add_domain), read the SELinux
<label/> and <imagelabel/> from the guest and use them for the
appliance. The appliance is statically labelled the same as the
guest, so it is able to read its disks.
However tell libvirt not to try relabelling the disks, to prevent
libvirt from disturbing the existing labels on the disks (in
particular when the libvirt connection is closed, we don't want
libvirt to try to restore some other label on the disks).
Updated with feedback from Matthew Booth.
When a disk is opened readonly, the libvirt attach-method privately
creates a qcow2 overlay on top.
This commit lets that overlay get an SELinux label, and sets it to the
imagelabel specified by guestfs_internal_set_libvirt_selinux_label.
The above only applies to the libvirt attach-method.
If set, this causes <seclabel model=selinux relabel=no> to be added to
the disk element in the libvirt XML.
It has no effect *except* on the libvirt attach method when SELinux
and sVirt is being used.
This internal API sets two SELinux labels in the handle (the process
label and the image label -- they are closely related).
If using the libvirt attach-method with SELinux and sVirt, then this
will cause the following XML to be added to the appliance definition:
<seclabel type=static model=selinux relabel=yes>
<label>[LABEL HERE]</label>
<imagelabel>[IMAGELABEL HERE]</imagelabel>
</seclabel>
It is ignored by other attach-methods.
libguestfs handles are not thread safe, and it's not safe even to read
settings from the handle from multiple threads (eg. guestfs_get_trace).
Stop doing this in the parallel library. This caused fairly
reproducible segfaults when you enabled '-x' and/or '-v'.
This fixes commit 34e77af1bf.
This function is no longer called from anywhere outside the library,
or even outside libvirt-domain.c.
This is just code motion, except for the size_t changes which are
required in order to avoid signed overflow optimization error:
assuming signed overflow does not occur when simplifying conditional
to constant [-Werror=strict-overflow]
