Signed-off-by: NCole Robinson <crobinso@redhat.com>

Signed-off-by: NCole Robinson <crobinso@redhat.com>

There are some path where the buffer is not passed to
virCommandAddArgBuffer and therefore the buffer might leak.

==191201== 1,010 bytes in 1 blocks are definitely lost in loss record 826 of 836
==191201==    at 0x4C2CE3F: malloc (vg_replace_malloc.c:298)
==191201==    by 0x4C2F1BF: realloc (vg_replace_malloc.c:785)
==191201==    by 0x5D39E82: virReallocN (viralloc.c:245)
==191201==    by 0x5D3E8F2: virBufferGrow (virbuffer.c:150)
==191201==    by 0x5D3E9C8: virBufferAdd (virbuffer.c:185)
==191201==    by 0x56EAC98: qemuBuildFloppyCommandLineControllerOptions (qemu_command.c:2162)
==191201==    by 0x56EB3E1: qemuBuildDisksCommandLine (qemu_command.c:2370)
==191201==    by 0x570055E: qemuBuildCommandLine (qemu_command.c:10315)
==191201==    by 0x575EA7F: qemuProcessCreatePretendCmd (qemu_process.c:6777)
==191201==    by 0x113DAB: testCompareXMLToArgv (qemuxml2argvtest.c:598)
==191201==    by 0x13A75B: virTestRun (testutils.c:180)
==191201==    by 0x138BE8: mymain (qemuxml2argvtest.c:2975)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Libvirt now tries to preserve all mounts under /dev in qemu namespaces.
The old rules only listed a set of known paths but those are no more enough.

I found some due to containers like /dev/.lxc/* and such but also /dev/console
and /dev/net/tun.

Libvirt is correct to do so, but we can no more predict the names properly, so
we modify the rule to allow a wildcard based pattern matching what libvirt does.
Acked-by: NJamie Strandboge <jamie@canonical.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Several cases were found needing /tmp, for example ceph will try to list /tmp
This is a compromise of security and usability:
 - we only allow generally enumerating the base dir
 - enumerating anything deeper in the dir is at least guarded by the
   "owner" restriction, but while that protects files of other services
   it won't protect qemu instances against each other as they usually run
   with the same user.
 - even with the owner restriction we only allow read for the wildcard
   path
Acked-by: NJamie Strandboge <jamie@canonical.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

If a guest runs unconfined <seclabel type='none'>, but libvirtd is
confined then the peer for signal can only be detected as
'unconfined'. That triggers issues like:
   apparmor="DENIED" operation="signal"
   profile="/usr/sbin/libvirtd" pid=22395 comm="libvirtd"
   requested_mask="send" denied_mask="send" signal=term peer="unconfined"

To fix this add unconfined as an allowed peer for those operations.

I discussed with the apparmor folks, right now there is no better
separation to be made in this case. But there might be further down the
road with "policy namespaces with scope and view control + stacking"

This is more a use-case addition than a fix to the following two changes:
- 3b1d19e6 AppArmor: add rules needed with additional mediation features
- b482925c apparmor: support ptrace checks
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: NJamie Strandboge <jamie@canonical.com>
Acked-by: Nintrigeri <intrigeri+libvirt@boum.org>

virt-manager's UI connection will need socket access for openGraphicsFD
to work - otherwise users will face a failed connection error when
opening the UI view.

Depending on the exact versions of libvirt and qemu involved this needs
either a rule from qemu to libvirt or vice versa.
Acked-by: NJamie Strandboge <jamie@canonical.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers. This means that we will no
longer overwrite the error from the API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers. This means that we will no
longer overwrite the error from the API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers. This means that we will no
longer overwrite the error from the API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers. This means that we will no
longer overwrite the error from the API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Rather than forcing the caller to generate an error, let's
generate the Username or Password error message failure if
the auth->cb fails. This is the last error path that needs
a specific message for various callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

If we never find the valid credtype in the list, then we'd return
NULL without an error signaled forcing the caller to generate one
that will probably be incorrect. Let's be specific.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path helpers make the checks, we can remove
them from here.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Before trying to call @auth->cb, let's ensure it exists.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Before trying to dereference @auth, let's ensure it's valid.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

The virSecretGetSecretString() helper looks up a secret for given
pool and returns its value in @secret_value and its length in
@secret_value_size. However, the trailing '\0' is not included in
either of the variables. This is because usually the value of the
secret is passed to some encoder (usually base64 encoder) where
the trailing zero must not be accounted for.

However, in two places we actually want the string as we don't
process it any further.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

As advertised in the previous commit, we need the list of
accessed files to also contain action that caused the $path to
appear on the list. Not only this enables us to fine tune our
white list rules it also helps us to see why $path is reported.
For instance:

  /run/user/1000/libvirt/libvirt-sock: connect: qemuxml2argvtest: QEMU XML-2-ARGV net-vhostuser-multiq
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The check-file-access.pl script is used to match access list
generated by virtestmock against whitelisted rules stored in
file_access_whitelist.txt. So far the rules are in form:

  $path: $progname: $testname

This is not sufficient because the rule does not take into
account 'action' that caused $path to appear in the list of
accessed files. After this commit the rule can be in new form:

  $path: $action: $progname: $testname

where $action is one from ("open", "fopen", "access", "stat",
"lstat", "connect"). This way the white list can be fine tuned to
allow say access() but not connect().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

So far we are setting only fake secret and storage drivers.
Therefore if the code wants to call a public NWFilter API (like
qemuBuildInterfaceCommandLine() and qemuBuildNetCommandLine() are
doing) the virGetConnectNWFilter() function will try to actually
spawn session daemon because there's no connection object set to
handle NWFilter driver.

Even though I haven't experienced the same problem with the rest
of the drivers (interface, network and node dev), the reasoning
above can be applied to them as well.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Update for the release of qemu 3.0.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NBing Niu <bing.niu@intel.com>

Semantically, there is no difference between an uninitialized worker
pool and an initialized worker pool with zero workers. Let's allow the
worker pool to be initialized for max_workers=0 as well then which
makes the API more symmetric and simplifies code. Validity of the
worker pool is delegated to virThreadPoolGetMaxWorkers instead.

This patch fixes segmentation faults in
virNetServerGetThreadPoolParameters and
virNetServerSetThreadPoolParameters for the case when no worker pool
is actually initialized (max_workers=0).
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed. Also, only auth is checked, but auth->cb, which that could
lead to a crash if the callback is NULL.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Instead of adding the same check for every drivers, execute the checks
in virAuthGetUsername and virAuthGetPassword. These funtions are called
when user is not set in the URI.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Currently iohelper's error log is recorded in virFileWrapperFdClose.
However, if something goes wrong the caller might not even get to
calling virFileWrapperFdClose and call virFileWrapperFdFree
directly. Therefore the error reporting should happen there.
Signed-off-by: Nxinhua.Cao <caoxinhua@huawei.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This proves libvirt can now handle high socket_id and
core_id values correctly and ensures we won't introduce
regressions in this area.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

While in most cases the values are going to be much
smaller than our arbitrary 4096 limit, there is really
no guarantee that would be the case: in fact, a few
aarch64 servers have been spotted in the wild with
core_id as high as 6216.

Take advantage of virBitmap's ability to automatically
alter its size at runtime to accomodate such values.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The latter are no longer used by libvirt, and the former
never were; moreover, both have a corresponding *_list
file which we can manipulate very conveniently using our
bitmap APIs, so dropping them makes sure in the future
developers will look into that rather than trying to
parse the kernel binary bitmaps.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

We already have a function which parses
thread_siblings_list for a CPU and returns the
corresponding bitmap, and a bunch of utility functions
that perform operations on bitmaps such as counting
the number of set bits: use those to implement the
function instead of having an additional ad-hoc parser
for thread_siblings.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Some of the data dumps didn't include them; luckily,
we're not actually missing any information since we
can recreate them by looking at the corresponding
thread_sibilings files.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Added by mistake with commit a0fdd2f6.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Unused since commit c67e04e2.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Most distributions we build RPMs on don't ship a
recent enough version of libiscsi, so we can't enable
the driver unconditionally. Add an explicit dependency
on the runtime package while at it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Commit 34a6962c added a BuildRequires for the
iscsi-direct backend, but we need the headers rather
than the runtime package to be available in order to
link against the library.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>