The code to select writeback was redundant, because current
qemu always supports cache=unsafe.
(cherry picked from commit 011c963926)
(cherry picked from commit 5be3a863c5)
They are _scratch_ drives so any data on them doesn't matter and can
be reconstructed in the event of a host system crash.
(cherry picked from commit 96cd7fcecb)
(cherry picked from commit 053061f66f)
This commit adds an optional 'cachemode' parameter to the 'add_drive'
API to control caching. This corresponds approximately to the
'-drive ...,cache=' parameter in qemu, but the choices are much more
restrictive, just 'writeback' or 'unsafe', for reasons outlined below.
The caching modes supported by recent QEMU are:
writeback:
- Reports data writes completed when data is present in the host
page cache.
Only safe provided guest correctly issues flush operations.
writethrough:
- Reports data writes completed only when each write has been
flushed to disk. Performance is reported as not good.
none:
- Uses O_DIRECT (avoids all interaction with host cache), but does
not ensure every write is flushed to disk.
Only safe provided guest correctly issues flush operations.
directsync:
- Uses O_DIRECT (avoids all interaction with host cache), and
ensures every write has been flushed to disk.
unsafe:
- No special handling.
Since the libguestfs appliance kernel always issues flush operations
(eg. for filesystem journalling and for sync) the following modes can
be ignored: 'directsync', 'writethrough'.
That leaves 'writeback', 'none' and 'unsafe'. However 'none' is both
a constant source of pain (RHBZ#994517), is inefficient because it
doesn't use the host cache, and does not give us any safety guarantees
over and above 'writeback'. Therefore we should ignore 'none'.
This leaves 'writeback' (safe) and 'unsafe' (fast, useful for scratch
disks), which is what we implement in this patch.
Note that the previous behaviour was to use 'none' if possible, else
to use 'writeback'. The new behaviour is to use 'writeback' only
which is (in safety terms) equivalent to 'none', and also faster and
less painful (RHBZ#994517).
This patch also allows you to specify a cache mode for network drives
which also previously defaulted to 'writeback'.
There is a considerable performance benefit to using unsafe (for
scratch disks only, of course). The C API tests only use scratch
disks (since they are just tests, the final state of the disk doesn't
matter), and this decreases total run time from 202 seconds to 163
seconds, about 25% faster.
(cherry picked from commit 749e947bb0)
(cherry picked from commit c7304d0c8e)
However earlier versions didn't have the --force option, so we
have to detect it.
(cherry picked from commit 59596810b0)
(cherry picked from commit 899d0af829)
If calling guestfs_list_filesystems with a disk image containing a
corrupt btrfs volume, the library would segfault. There was a missing
check for a NULL return from guestfs_btrfs_subvolume_list.
This adds a check, returning the real error up through the stack and
out of guestfs_list_filesystems.
This is potentially a denial of service if processing disk images from
untrusted sources, but is not exploitable.
Thanks: Jeff Bastian for reporting the bug.
(cherry picked from commit d70ceb4cbe)
When using the guestfish --remote or guestfish --listen options,
guestfish would create a socket in a known location
(/tmp/.guestfish-$UID/socket-$PID).
The location has to be a known one in order for both ends to
communicate. However no checking was done that the containing
directory (/tmp/.guestfish-$UID) is owned by the user. Thus another
user could create this directory and potentially modify sockets owned
by another user's guestfish client or server.
This commit fixes the issue by creating the directory unconditionally,
and then checking that the directory has the correct owner and
permissions, thus preventing another user from creating the directory
first.
If guestfish sees a suspicious socket directory it will print an error
like this and exit with an error status:
guestfish: '/tmp/.guestfish-1000' is not a directory or has insecure owner or permissions
Thanks: Michael Scherer for discovering this issue.
Version 2:
- Add assigned CVE number.
- Update documentation.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
(cherry picked from commit 54fb09e052)
This should be safe, and avoids the whole issue of whether a guest
uses systemd or not. Also it is possible to switch init systems
(eg. by specifying init= on the command line) so it's not even clear
if a guest "is" systemd.
Thanks: Tom Gundersen on #systemd.
This updates/fixes commit 596de56a43.
(cherry picked from commit 9aa13e0574)
Not necessary to wait for syslog since (a) we do our own logging
to a file and (b) syslog might not be installed.
(cherry picked from commit cff95392f5)
Ubuntu 13.10 has /etc/systemd but uses Upstart. This confuses the
script because it assumed that if you have /etc/systemd then you are
using systemd. Ubuntu includes systemd services (inherited from
Debian) but they just don't run.
(cherry picked from commit 596de56a43)
Commit c598e14052 exports
LD_PRELOAD=/lib64/libSegFault.so so that guestfsd and processes that
it runs will produce descriptive stack traces.
However it exports it to everything including the virt-rescue shell.
But if we are chrooting into a guest which doesn't have this file (or
indeed any guest) we should not use LD_PRELOAD.
Therefore unset LD_PRELOAD in the rescue shell.
See also related commit 21e5fc811e.
(cherry picked from commit f7ca38b728)
The third parameter (number of bytes to copy) was given as an offset
relative to dest, when it should be relative to src. This fixes some
valgrind warnings I happened across.
(cherry picked from commit da85de8a42)
Using guestfs_exists on a symlink which existed but pointed to a
non-existent file was returning false. However exists obviously
should not be following the symlink in the first place.
(cherry picked from commit 93793db049)
Removing this directory breaks Ubuntu guests.
This change adds a utility function which removes only files from a
directory. This is a safer way to clean cache directories etc.
(cherry picked from commit dfa52c63b1)
Commit c598e14052 exports
LD_PRELOAD=/lib64/libSegFault.so so that guestfsd and processes that
it runs will produce descriptive stack traces.
However if we chroot into /sysroot (ie. CHROOT_IN/CHROOT_OUT) and if
the libSegFault.so library does not exist inside the chroot (as is the
case on Debian guests) then we cannot run any processes. In any case
we *don't* want to necessarily run this library from the guest.
The proper way to fix this is to confine all chrooting to a
subprocess, but that's a big change to guestfsd which we'll have to do
one day. For now, unset LD_PRELOAD once guestfsd starts up.
(cherry picked from commit 21e5fc811e)
The old parser had several problems: firstly it called the error path
sometimes without calling reply_with_error causing a protocol hang.
More seriously it had hard-coded line numbers, and since Fedora 21 the
output of xfs_info has changed, moving lines around.
Change the parser to be more robust against added fields by using the
first name on the line as the section name, thus 'bsize=' is
interpreted differently depending on whether it appears in the "data"
section or the "naming" section.
Ensure also that we don't call the error path without calling
reply_with_error, which is a side-effect of the above change.
(cherry picked from commit 8abd0a83b3)
When 'mount -o loop' and similar commands are used, the loop module is
loaded automatically by the kernel when /dev/loop-control is accessed.
/dev/loop-control is created semi-statically by an unholy and
overcomplex combination of kmod static-nodes and systemd-tmpfiles
(instead of using, say, just udev or even just a simple series of
mknod commands).
(cherry picked from commit e2895b19bb)
tests/c-api would fail from time to time if --enable-valgrind-daemon
was configured. There was no obvious memory leak. It looks as if the
overhead of valgrind was sufficient to break long-running tests such
as this one.
(cherry picked from commit d0ef2ff9b6)
guestfs_case_sensitive_path does not test for file existence. We have
to test for it explicitly.
This updates commit 9ea6e97014. See the
description of that commit for more details.
(cherry picked from commit bae6d5cc63)
