When adding an automatically allocated port to a well-formed migration
URI, keep it well-formed:

  tcp://1.2.3.4/  ->  tcp://1.2.3.4/:12345   # wrong
  tcp://1.2.3.4/  ->  tcp://1.2.3.4:12345/   # fixed
  tcp://1.2.3.4   ->  tcp://1.2.3.4:12345    # still works
  tcp:1.2.3.4     ->  tcp:1.2.3.4:12345      # still works (old syntax)
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Introduced by commit 0f31f7b7.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

For inexplicable reasons, many of the 3rd party package deps
were left against the 'libvirt-daemon' RPM when the drivers
were split out. This makes a minimal install heavier that
it should be. Push them all down into libvirt-daemon-driver-XXX
so they're only pulled in when truly needed

With this change applied, a minimal install of just the
libvirt-daemon-driver-lxc RPM is reduced by 41 MB on a
Fedora 19 host.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Expand the "secmodel" XML fragment of "host" with a sequence of
baselabel's which describe the default security context used by
libvirt with a specific security model and virtualization type:

<secmodel>
  <model>selinux</model>
  <doi>0</doi>
  <baselabel type='kvm'>system_u:system_r:svirt_t:s0</baselabel>
  <baselabel type='qemu'>system_u:system_r:svirt_tcg_t:s0</baselabel>
</secmodel>
<secmodel>
  <model>dac</model>
  <doi>0</doi>
  <baselabel type='kvm'>107:107</baselabel>
  <baselabel type='qemu'>107:107</baselabel>
</secmodel>

"baselabel" is driver-specific information, e.g. in the DAC security
model, it indicates USER_ID:GROUP_ID.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

virSecurityManagerGetBaseLabel queries the default settings used by
a security model.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

Merge the functions 'virSecurityDACSetUser' and
'virSecurityDACSetGroup' into 'virSecurityDACSetUserAndGroup'.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

Allow adjust the number of commands to remember in the command
history.

* tools/virsh.c (vshReadlineInit): Read and sanity the
VIRSH_HISTSIZE variable.
(VIRSH_HISTSIZE_MAX): New constant.
* tools/virsh.pod: Document VIRSH_HISTSIZE variable.
Signed-off-by: NEric Blake <eblake@redhat.com>

Since we haven't quite frozen yet, it's time to pick up some
gnulib fixes.  I know at least cygwin benefits from this update.

* .gnulib: Update to latest, in part for cygwin compilation.
Signed-off-by: NEric Blake <eblake@redhat.com>

The lxcContainerSetID() method prints a misleading log
message about setting the uid/gid when no ID map is
present in the XML config. Skip the debug message in
this case.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

s/no/not
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

Commit '922b7fda' resulted in two DEADCODE warnings from Coverity in
remoteDispatchAuthPolkit and virAccessDriverPolkitFormatProcess.
Commit '604ae657' modified the daemon.c code to remove the deadcode
issue, but did not do so for viracessdriverpolkit.c. This just mimics
the same changes

Commit e962a579 added 'attach-disk --shareable', even though we
already had 'attach-disk --mode=shareable'.  Worse, if the user
types 'attach-disk --mode=readonly --shareable', we create
non-sensical XML.  The best solution is just to undocument the
duplicate spelling, by having it fall back to the preferred
spelling.

* tools/virsh-domain.c (cmdAttachDisk): Let alias handling fix our
mistake in exposing a second spelling for an existing option.
* tools/virsh.pod: Fix documentation.
Signed-off-by: NEric Blake <eblake@redhat.com>

We want to treat 'attach-disk --shareable' as an undocumented
alias for 'attach-disk --mode=shareable'.  By improving our
alias handling, we can allow all such --bool -> --opt=value
replacements, and guarantee up front that the alias is not
mixed with its replacement.

* tools/virsh.c (vshCmddefOptParse, vshCmddefGetOption): Add
support for expanding bool alias to --opt=value.
(opts_echo): Add another alias to test it.
* tests/virshtest.c (mymain): Test it.
Signed-off-by: NEric Blake <eblake@redhat.com>

According to the following valgrind output, there seems to be a
invalid limit for the iterator (captured on Fedora 19):

==3945== Invalid read of size 1
==3945==    at 0x1E1FA410: libxlVmStart (libxl_driver.c:475)
==3945==    by 0x1E1FAD9A: libxlDomainCreateWithFlags (libxl_driver.c:2633)
==3945==    by 0x5187D46: virDomainCreate (libvirt.c:9439)
==3945==    by 0x13BAA6: remoteDispatchDomainCreateHelper (remote_dispatch.h:2910)
==3945==    by 0x51DE5B9: virNetServerProgramDispatch (virnetserverprogram.c:435)
==3945==    by 0x51D93E7: virNetServerHandleJob (virnetserver.c:165)
==3945==    by 0x50F5BF4: virThreadPoolWorker (virthreadpool.c:144)
==3945==    by 0x50F5670: virThreadHelper (virthreadpthread.c:161)
==3945==    by 0x8046C52: start_thread (pthread_create.c:308)
==3945==    by 0x8758E1C: clone (clone.S:113)
==3945==  Address 0x23424d81 is 0 bytes after a block of size 1 alloc'd
==3945==    at 0x4A08121: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3945==    by 0x50B1F8C: virAllocN (viralloc.c:189)
==3945==    by 0x1E1FA3CA: libxlVmStart (libxl_driver.c:468)
==3945==    by 0x1E1FAD9A: libxlDomainCreateWithFlags (libxl_driver.c:2633)
==3945==    by 0x5187D46: virDomainCreate (libvirt.c:9439)
==3945==    by 0x13BAA6: remoteDispatchDomainCreateHelper (remote_dispatch.h:2910)
==3945==    by 0x51DE5B9: virNetServerProgramDispatch (virnetserverprogram.c:435)
==3945==    by 0x51D93E7: virNetServerHandleJob (virnetserver.c:165)
==3945==    by 0x50F5BF4: virThreadPoolWorker (virthreadpool.c:144)
==3945==    by 0x50F5670: virThreadHelper (virthreadpthread.c:161)
==3945==    by 0x8046C52: start_thread (pthread_create.c:308)
==3945==    by 0x8758E1C: clone (clone.S:113)
==3945==

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1013045Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Reported in https://bugzilla.redhat.com/show_bug.cgi?id=1022872

* tools/virsh.pod: s/COMMMANDS/COMMANDS/
Signed-off-by: NEric Blake <eblake@redhat.com>

... the same way we ignore other TAGS
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

On RHEL 5, make syntax-check was failing because even strings like
'int isTempChain' matched the 'int i' rule.  To be honest, I haven't
found the root cause, but the change added makes it work as expected
and keeps the proper behavior on newer systems as well.

Commit d76227be added functions virDomainCreateWithFiles and
virDomainCreateXMLWithFiles, but there was a little piece missing in
python bindings.  This patch fixes proper passing of file descriptors
in the overwrites of these functions.

Currently, we ignore whether dnsmasqCapsRefresh succeeds or fails. We
shouldn't do that as we may generate wrong dnsmasq command line (what
is done just a few lines below).
Signed-off-by: NHongwei Bi <hwbi2008@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While LOCAL_PEERCRED on the BSDs does not return the pid information of
the peer, Mac OS X 10.8 added LOCAL_PEERPID to retrieve the pid so we
should use that when its available to get that information.

* ChangeLog-old: s/guarentee/guarantee/
Signed-off-by: NEric Blake <eblake@redhat.com>

On systems where gnutls uses libgcrypt, I'm seeing the following
build failure

libvirt.c:314: error: variable 'virTLSThreadImpl' has initializer but incomplete type
libvirt.c:319: error: 'GCRY_THREAD_OPTION_PTHREAD' undeclared here (not in a function)
...

Fix by undefining WITH_GNUTLS_GCRYPT in config-post.h

There are still two places where we are using 1bit width unsigned
integer to store a boolean. There's no real need for this and these
occurrences can be replaced with 'bool'.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After commit 3e2f27e1, I've noticed build failures of virt-login-shell
when libapparmor-devel is installed on the build host

CCLD     virt-login-shell
../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-vircommand.o):
In function `virExec':
/home/jfehlig/virt/upstream/libvirt/src/util/vircommand.c:653: undefined
reference to `aa_change_profile'
collect2: error: ld returned 1 exit status

I was about to commit an easy fix under the build-breaker rule
(build-fix-1.patch), but thought to extend the notion of SECDRIVER_LIBS
to SECDRIVER_CFLAGS, and use both throughout src/Makefile.am where it
makes sense (build-fix-2.patch).

Should I just stick with the simple fix, or is something along the lines
of patch 2 preferred?

Regards,
Jim

>From a0f35945f3127ab70d051101037e821b1759b4bb Mon Sep 17 00:00:00 2001
From: Jim Fehlig <jfehlig@suse.com>
Date: Mon, 21 Oct 2013 15:30:02 -0600
Subject: [PATCH] build: fix virt-login-shell build with apparmor

With libapparmor-devel installed, virt-login-shell fails to link

CCLD     virt-login-shell
../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-vircommand.o): In function `virExec':
/home/jfehlig/virt/upstream/libvirt/src/util/vircommand.c:653: undefined reference to `aa_change_profile'
collect2: error: ld returned 1 exit status

Fix by linking libvirt_setuid_rpc_client with previously determined
SECDRIVER_LIBS in src/Makefile.am.  While at it, introduce SECDRIVER_CFLAGS
and use both throughout src/Makefile.am where it makes sense.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Currently, if access(path, mode) is invoked, we check if @path has this
special prefix SYSFS_PREFIX. If it does, we modify the path a bit and
call realaccess. If it doesn't we act just like a wrapper and call
realaccess directly. However, we are mocking fopen() as well. And as one
can clearly see there, fopen("/proc/cgroups") will succeed. Hence, we
have an error in our mocked access(): We need to check whether @path is
not equal to /proc/cgroups as it may not exists on real system we're
running however we definitely know how to fopen() it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As stated in the comment above introduction of the lv_abs_top_builddir
variable, older automake doesn't provide abs_top_builddir variable.
Hence, we are creating our own one with lv_ prefix. However, when
exporting env variables to the tests, the variables are not evaluated
but only substituted. Hence:

  LIBVIRT_DRIVER_DIR="$(abs_top_builddir)/src/.libs"

is set to "/src/.libs" with old automake (even though we *think* we've
set the $abs_top_builddir variable just a few line above).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In commit b46c4787 I changed the code to
watch long running jobs in virsh. Unfortunately I didn't take into
account that poll may get a hangup if the terminal is not a TTY and will
be closed.

This patch avoids polling the STDIN fd when there's no TTY.

s/informations/information
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

HW_PHYSMEM is available on Mac OS X as well as FreeBSD, however,
its resulting value for Mac OS X is 32 bits. Mac OS X provides
HW_MEMSIZE that is 64 bits version of HW_PHYSMEM. We have to use it.

I tested the patch on Mac OS X 10.6.8, 10.7.4, 10.8.5 and FreeBSD 9.2.
Signed-off-by: NRyota Ozaki <ozaki.ryota@gmail.com>

This patch (and the two patches that precede it) resolve:

  https://bugzilla.redhat.com/show_bug.cgi?id=1005682

When libvirt was changed to delay the final cleanup of device removal
until the qemu process had signaled it with a DEVICE_DELETED event for
that device, the hostdev removal function
(qemuDomainRemoveHostDevice()) was written to properly handle the
removal of a hostdev that was actually an SRIOV virtual function
(defined with <interface type='hostdev'>). However, the function used
to search for a device matching the alias name provided in the
DEVICE_DELETED message (virDomainDefFindDevice()) would search through
the list of netdevs before hostdevs, so qemuDomainRemoveHostDevice()
was never called; instead the netdev function,
qemuDomainRemoveNetDevice() (which *doesn't* properly cleanup after
removal of <interface type='hostdev'>), was called.

(As a reminder - each <interface type='hostdev'> results in a
virDomainNetDef which contains a virDomainHostdevDef having a parent
type of VIR_DOMAIN_DEVICE_NET, and parent.data.net pointing back to
the virDomainNetDef; both Defs point to the same device info object
(and the info contains the device's "alias", which is used by qemu to
identify the device). The virDomainHostdevDef is added to the domain's
hostdevs list *and* the virDomainNetDef is added to the domain's nets
list, so searching either list for a particular alias will yield a
positive result.)

This function modifies the qemuDomainRemoveNetDevice() to short
circuit itself and call qemu DomainRemoveHostDevice() instead when the
actual device is a VIR_DOMAIN_NET_TYPE_HOSTDEV (similar logic to what
is done in the higher level qemuDomainDetachNetDevice())

Note that even if virDomainDefFindDevice() changes in the future so
that it finds the hostdev entry first, the current code will continue
to work properly.

pure code movement to setup for next patch.

This function was called in three places, and in each the call was
qualified by a slightly different conditional. In reality, this
function should only be called for a hostdev if all of the following
are true:

  1) mode='subsystem'
  2) type='pci'
  3) there is a parent device definition which is an <interface>
     (VIR_DOMAIN_DEVICE_NET)

We can simplify the callers and make them more consistent by checking
these conditions at the top ov qemuDomainHostdevNetConfigRestore and
returning 0 if one of them isn't satisfied.

The location of the call to qemuDomainHostdevNetConfigRestore() has
also been changed in the hot-plug case - it is moved into the caller
of its previous location (i.e. from qemuDomainRemovePCIHostDevice() to
qemuDomainRemoveHostDevice()). This was done to be more consistent
about which functions pay attention to whether or not this is one of
the special <interface> hostdevs or just a normal hostdev -
qemuDomainRemoveHostDevice() already contained a call to
networkReleaseActualDevice() and virDomainNetDefFree(), so it makes
sense for it to also handle the resetting of the device's MAC address
and vlan tag (which is what's done by
qemuDomainHostdevNetConfigRestore()).

Many people will not want the setuid virt-login-shell binary
installed by default, so move it into a separate sub-RPM
named libvirt-login-shell. This RPM is only generated if
LXC is enabled
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Avoid people introducing security flaws in their apps by
forbidding the use of libvirt.so in setuid programs, with
a check in virInitialize.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Most of the usage of getuid()/getgid() is in cases where we are
considering what privileges we have. As such the code should be
using the effective IDs, not real IDs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We already have stubs for getuid, geteuid, getgid but
not for getegid. Something in gnulib already does a
check for it during configure, so we already have the
HAVE_GETEGID macro defined.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We don't want setuid programs automatically spawning libvirtd,
so disable any use of autostart when setuid.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We don't know enough about quality of external libraries used
for non-UNIX transports, nor do we want to spawn external
commands when setuid. Restrict to the bare minimum which is
UNIX transport for local usage. Users shouldn't need to be
running setuid if connecting to remote hypervisors in any
case.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The use of getenv is typically insecure, and we want people
to use our wrappers, to force them to think about setuid
needs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditional use of getenv is not secure in setuid env.
While not all libvirt code runs in a setuid env (since
much of it only exists inside libvirtd) this is not always
clear to developers. So make all the code paranoid, even
if it only ever runs inside libvirtd.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>