If no user identity is available, some operations may wish to
use the system identity. ie the identity of the current process
itself. Add an API to get such an identity.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

To allow any internal API to get the current identity, add APIs
to associate a virIdentityPtr with the current thread, via a
thread local
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce a local object virIdentity for managing security
attributes used to form a client application's identity.
Instances of this object are intended to be used as if they
were immutable, once created & populated with attributes
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

A socket object has various pieces of security data associated
with it, such as the SELinux context, the SASL username and
the x509 distinguished name. Add new APIs to virNetServerClient
and related modules to access this data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit 82d5fe54

    qemu: check backing chains even when cgroup is omitted

added backing file checks just before the code that removes optional
disks if they are not present. However, the backing chain code fails in
case the disk file does not exist, which makes qemuProcessStart fail
regardless on configured startupPolicy.

Note that startupPolicy implementation is still wrong after this patch
since it only check the first file in a possible chain. It should rather
check the complete backing chain. But this is an existing limitation
that can be solved later. After all, startupPolicy is most useful for
CDROM images and they won't make use of backing files in most cases.

QEMU 1.3 and newer support an alternative URI-based syntax to specify
the location of an NBD server.  Libvirt can keep on using the old
syntax in general, but only the URI syntax supports IPv6 addresses.

The URI syntax also supports relative paths to Unix sockets.  These
should never be used but aren't explicitly blocked either by the parser,
so support it just in case.

The URI syntax is intentionally compatible with Gluster's, and the
code can be reused.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

This reuses the XML format that was introduced for Gluster.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

These are supported by nbd-server and by the NBD server that QEMU
embeds for live image access.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Move the code to an external function, and structure it to prepare
the addition of new features in the next few patches.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Enable more testing of NBD parsing, to ensure rewrites work.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

We've already scrubbed for comparisons of 'uid_t == -1' (which fail
on platforms where uid_t is a u16), but another one snuck in.

* src/util/virutil.c (virSetUIDGIDWithCaps): Correct uid comparison.
* cfg.mk (sc_prohibit_risky_id_promotion): New rule.

QEMU added -drive in 2007, and NBD in 2008.  Both appeared first in
release 0.10.0.  Thus the code to support network disks without -drive
is dead, and in fact it incorrectly escapes commas.  Drop it.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

After we switched to C99 initialization, I noticed there were many
places where the specification of .flags parameter differed.  After
going through many options and deciding whether to unify the
initialization to be '.flags = 0' or '.flags = VSH_OFLAG_NONE', I
realized both can be removed and it makes the code easier to go
through.

According to the man page, the memspec parameter should have the
'--memspec' option mandatory and this is as close as we can get to
that.  What this change does is explained below.

man virsh:

snapshot-create-as ... [[--live] [--memspec memspec]]

virsh help snapshot-create-as before this patch:

  SYNOPSIS
    snapshot-create-as ... [<memspec>] ...
...
  OPTIONS
    [--memspec] <string> ...

virsh help snapshot-create-as after this patch:

  SYNOPSIS
    snapshot-create-as ... [--memspec <string>] ...
...
  OPTIONS
    --memspec <string> ...

The vshInit initializes ctl->debug by which vshDebug (which is also
called in vshParseArgv) decides whether to print out the message or
not.

When getting CPUs' information, it assumes that CPU indexes
are not contiguous. But for ppc64 platform, CPU indexes are not
contiguous because SMT is needed to be disabled, so CPU information
is not right on ppc64 and vpuinfo, vcpupin can't work corretly.

This patch is to remove the assumption to be compatible with ppc64.

Test:
   4 vcpus are assigned to one VM and execute vcpuinfo command.

   Without patch: There is only one vcpu informaion can be listed.
   With patch: All vcpus' information can be listed correctly.
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>

The text version
of LGPLv2.1 available at
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt is slightly
different from COPYING.LIB:
- several paragraphs were rewrapped
- the FSF address has changed, so the license has been changed to
  indicate the newer address

I've checked that there are no changes in the license text apart from
the updated address, which is what I want to fix with this commit.

Signed-off-by: NYanbing Du <ydu@redhat.com>

This patch adds auditing of resources used by Virtio RNG devices. Only
resources on the local filesystems are audited.

The audit logs look like:

For the 'random' backend:
type=VIRT_RESOURCE msg=audit(1363099126.643:31): pid=995252 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=rng reason=start vm="qcow-test" uuid=118733ed-b658-3e22-a2cb-4fe5cb3ddf79 old-rng="?" new-rng="/dev/random": exe="/home/pipo/libvirt/daemon/.libs/libvirtd" hostname=? addr=? terminal=pts/0 res=success'

For local character device source:
type=VIRT_RESOURCE msg=audit(1363100164.240:96): pid=995252 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=rng reason=start vm="qcow-test" uuid=118733ed-b658-3e22-a2cb-4fe5cb3ddf79 old-rng="?" new-rng="/tmp/unix.sock": exe="/home/pipo/libvirt/daemon/.libs/libvirtd" hostname=? addr=? terminal=pts/0 res=success'

Adding test cases for virtio-scsi and virtio-rng. Since ccw is covering
the superset of the s390 bus handling, these are deemed to be sufficient.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Newer versions of QEMU support virtio-scsi and virtio-rng devices
on the virtio-s390 and ccw buses. Adding capability detection,
address assignment and command line generation for that.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

QEMU_CAPS_VIRTIO_SCSI_PCI implies that virtio-scsi is only supported
for the PCI bus, which is not the case. Remove the _PCI suffix.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

My commit 7a2e845a (and its
prerequisites) managed to effectively ignore the
clear_emulator_capabilities setting in qemu.conf (visible in the code
as the VIR_EXEC_CLEAR_CAPS flag when qemu is being exec'ed), with the
result that the capabilities are always cleared regardless of the
qemu.conf setting. This patch fixes it by passing the flag through to
virSetUIDGIDWithCaps(), which uses it to decide whether or not to
clear existing capabilities before adding in those that were
requested.

Note that the existing capabilities are *always* cleared if the new
process is going to run as non-root, since the whole point of running
non-root is to have the capabilities removed (it's still possible to
maintain individual capabilities as needed using the capBits argument
though).

Multi-head QXL support is so useful that distros have started to
backport it to qemu earlier than 1.2.  After discussion with
Alon Levy, we determined that the existence of the qxl-vga.surfaces
property is a reliable indicator of whether '-device qxl-vga' works,
or whether we have to stick to the older '-vga qxl'.  I'm leaving
in the existing check for QEMU_CAPS_DEVICE_VIDEO_PRIMARY tied to
qemu 1.2 and newer (in case qemu is built without qxl support),
but for those distros that backport qxl, this additional capability
check will allow the correct command line for both RHEL 6.3 (which
lacks the feature) and RHEL 6.4 (where qemu still claims to be
version 0.12.2.x, but has backported multi-head qxl).

* src/qemu/qemu_capabilities.c (virQEMUCapsObjectPropsQxlVga): New
property test.
(virQEMUCapsExtractDeviceStr): Probe for backport of new
capability to qemu earlier than 1.2.
* tests/qemuhelpdata/qemu-kvm-1.2.0-device: Update test.
* tests/qemuhelpdata/qemu-1.2.0-device: Likewise.
* tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel62-beta-device:
Likewise.

The src/lxc/lxc_*_dispatch.h files only had deps on the
RPC generator script & the XDR definition file. So when
the Makefile.am args passed to the generator were change,
the disaptch code was not re-generated. This caused a
build failure

  CC       libvirt_lxc-lxc_controller.o
lxc/lxc_controller.c: In function 'virLXCControllerSetupServer':
lxc/lxc_controller.c:718:47: error: 'virLXCMonitorProcs' undeclared (first use in this function)
lxc/lxc_controller.c:718:47: note: each undeclared identifier is reported only once for each function it appears in
lxc/lxc_controller.c:719:47: error: 'virLXCMonitorNProcs' undeclared (first use in this function)
make[3]: *** [libvirt_lxc-lxc_controller.o] Error 1

For added fun, the generated files were not listed in
CLEANFILES, so only a 'git clean -f' would fix the build
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit 027bf2ea used the wrong offset: the text field at the start
of the header has 64 bytes, not 68. [1]

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

[1] https://forums.virtualbox.org/viewtopic.php?p=29267#p29267

The naming used in the RPC protocols for the LXC monitor and
lock daemon confused the script used to generate systemtap
helper functions. Rename the LXC monitor protocol symbols to
reduce confusion. Adapt the gensystemtap.pl script to cope
with the LXC monitor / lock daemon naming conversions.

This has no functional impact on RPC wire protocol, since
names are only used in the C layer
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When converting to virObject, the probes on the 'Free' functions
were removed on the basis that there is a probe on virObjectFree
that suffices. This puts a burden on people writing probe scripts
to identify which object is being dispose. This adds back probes
in the 'Dispose' functions and updates the rpc monitor systemtap
example to use them
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Normally libvirtd should run with a SELinux label

  system_u:system_r:virtd_t:s0-s0:c0.c1023

If a user manually runs libvirtd though, it is sometimes
possible to get into a situation where it is running

  system_u:system_r:init_t:s0

The SELinux security driver isn't expecting this and can't
parse the security label since it lacks the ':c0.c1023' part
causing it to complain

  internal error Cannot parse sensitivity level in s0

This updates the parser to cope with this, so if no category
is present, libvirtd will hardcode the equivalent of c0.c1023.

Now this won't work if SELinux is in Enforcing mode, but that's
not an issue, because the user can only get into this problem
if in Permissive mode. This means they can now start VMs in
Permissive mode without hitting that parsing error
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Pull the code which parses the current process MCS range
out of virSecuritySELinuxMCSFind and into a new method
virSecuritySELinuxMCSGetProcessRange.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The body of the loop in virSecuritySELinuxMCSFind would
directly 'return NULL' on OOM, instead of jumping to the
cleanup label. This caused a leak of several local vars.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If an LXC domain failed to start because of a bogus SELinux
label, virLXCProcessStart would call VIR_CLOSE(0) by mistake.
This is because the code which initializes the member of the
ttyFDs array to -1 got moved too far away from the place where
the array is first allocated.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When opening a stream to a device which is a TTY, that device
may become the controlling TTY of libvirtd, if libvirtd was
daemonized. This in turn means when the other end of the stream
closes, libvirtd gets SIGHUP, causing it to reload its config.
Prevent this by forcing O_NOCTTY on all streams that are opened
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Qemu's implementation of virtio RNG supports rate limiting of the
entropy used. This patch exposes the option to tune this functionality.

This patch is based on qemu commit 904d6f588063fb5ad2b61998acdf1e73fb4

The rate limiting is exported in the XML as:
<devices>
  ...
  <rng model='virtio'>
    <rate bytes='123' period='1234'/>
    <backend model='random'/>
  </rng>
  ...

In debug mode, the bug failed to start vm
error: Failed to start domain rhel5u9
error: internal error Out of space while reading console log output:
...

This adds and corrects testcases for virtio devices on s390
guests.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

We didn't yet expose the virtio device attach and detach functionality
for s390 domains as the device hotplug was very limited with the old
virtio-s390 bus. With the CCW bus there's full hotplug support for
virtio devices in QEMU, so we are adding this to libvirt too.

Since the virtio hotplug isn't limited to PCI anymore, we change the
function names from xxxPCIyyy to xxxVirtioyyy, where we handle all
three virtio bus types.
Signed-off-by: NJ.B. Joret <jb@linux.vnet.ibm.com>
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

This commit adds the QEMU driver support for CCW addresses. The
current QEMU only allows virtio devices to be attached to the
CCW bus. We named the new capability indicating that support
QEMU_CAPS_VIRTIO_CCW accordingly.

The fact that CCW devices can only be assigned to domains with a
machine type of s390-ccw-virtio requires a few extra checks for
machine type in qemu_command.c on top of querying
QEMU_CAPS_VIRTIO_{CCW|S390}.

The majority of the new functions deals with CCW address generation
and management.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Add necessary handling code for the new s390 CCW address type to
virDomainDeviceInfo. Further, introduce  memory management, XML
parsing, output formatting and range validation for the new
virDomainDeviceCCWAddress type.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

The native bus for s390 I/O is called CCW (channel command word).
As QEMU has added basic support for the CCW bus, i.e. the
ability to assign CCW devnos (bus addresses) to devices.
Domains with the new machine type s390-ccw-virtio can use the
CCW bus. Currently QEMU will only allow to define virtio
devices on the CCW bus.
Here we add the new machine type and the new device address to the
schema definition and add a new paragraph to the domain XML
documentation.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>