- 09 3月, 2017 1 次提交
-
-
由 John Ferlan 提交于
Create a helper which will create the secinfo used for disks, hostdevs, and chardevs. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 07 3月, 2017 2 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 06 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Now that we have some qemuSecurity wrappers over virSecurityManager APIs, lets make sure everybody sticks with them. We have them for a reason and calling virSecurityManager API directly instead of wrapper may lead into accidentally labelling a file on the host instead of namespace. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 21 2月, 2017 1 次提交
-
-
由 Marc Hartmayer 提交于
The functions in virCommand() after fork() must be careful with regard to accessing any mutexes that may have been locked by other threads in the parent process. It is possible that another thread in the parent process holds the lock for the virQEMUDriver while fork() is called. This leads to a deadlock in the child process when 'virQEMUDriverGetConfig(driver)' is called and therefore the handshake never completes between the child and the parent process. Ultimately the virDomainObjectPtr will never be unlocked. It gets much worse if the other thread of the parent process, that holds the lock for the virQEMUDriver, tries to lock the already locked virDomainObject. This leads to a completely unresponsive libvirtd. It's possible to reproduce this case with calling 'virsh start XXX' and 'virsh managedsave XXX' in a tight loop for multiple domains. This commit fixes the deadlock in the same way as it is described in commit 61b52d2e. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
- 20 2月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
When enabling virgl, qemu opens /dev/dri/render*. So far, we are not allowing that in devices CGroup nor creating the file in domain's namespace and thus requiring users to set the paths in qemu.conf. This, however, is suboptimal as it allows access to ALL qemu processes even those which don't have virgl configured. Now that we have a way to specify render node that qemu will use we can be more cautious and enable just that. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far, qemuDomainGetHostdevPath has no knowledge of the reasong it is called and thus reports /dev/vfio/vfio for every VFIO backed device. This is suboptimal, as we want it to: a) report /dev/vfio/vfio on every addition or domain startup b) report /dev/vfio/vfio only on last VFIO device being unplugged If a domain is being stopped then namespace and CGroup die with it so no need to worry about that. I mean, even when a domain that's exiting has more than one VFIO devices assigned to it, this function does not clean /dev/vfio/vfio in CGroup nor in the namespace. But that doesn't matter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
由 Michal Privoznik 提交于
So far, we are allowing /dev/vfio/vfio in the devices cgroup unconditionally (and creating it in the namespace too). Even if domain has no hostdev assignment configured. This is potential security hole. Therefore, when starting the domain (or hotplugging a hostdev) create & allow /dev/vfio/vfio too (if needed). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
由 Michal Privoznik 提交于
Since these two functions are nearly identical (with qemuSetupHostdevCgroup actually calling virCgroupAllowDevicePath) we can have one function call the other and thus de-duplicate some code. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
- 15 2月, 2017 2 次提交
-
-
由 Michal Privoznik 提交于
The bare fact that mnt namespace is available is not enough for us to allow/enable qemu namespaces feature. There are other requirements: we must copy all the ACL & SELinux labels otherwise we might grant access that is administratively forbidden or vice versa. At the same time, the check for namespace prerequisites is moved from domain startup time to qemu.conf parser as it doesn't make much sense to allow users to start misconfigured libvirt just to find out they can't start a single domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
mknod() is affected my the current umask, so we're not guaranteed the newly-created device node will have the right permissions. Call chmod(), which is not affected by the current umask, immediately afterwards to solve the issue. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1421036
-
- 13 2月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
This controller only allows up to 15 ports. https://bugzilla.redhat.com/show_bug.cgi?id=1375417
-
- 09 2月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Just like we need wrappers over other virSecurityManager APIs, we need one for virSecurityManagerSetImageLabel and virSecurityManagerRestoreImageLabel. Otherwise we might end up relabelling device in wrong namespace. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 08 2月, 2017 6 次提交
-
-
由 Michal Privoznik 提交于
Firstly, instead of checking for next->path the virStorageSourceIsEmpty() function should be used which also takes disk type into account. Secondly, not every disk source passed has the correct type set (due to our laziness). Therefore, instead of checking for virStorageSourceIsBlockLocal() and also S_ISBLK() the former can be refined to just virStorageSourceIsLocalStorage(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, one missed bit. This time without this commit there is no /dev entry in the namespace of the qemu process when doing disk snapshots or block-copy. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
These functions do not need to see the whole virDomainDiskDef. Moreover, they are going to be called from places where we don't have access to the full disk definition. Sticking with virStorageSource is more than enough. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Since its introduction in 81df2150 this variable was never used. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There is no need for this. None of the namespace helpers uses it. Historically it was used when calling secdriver APIs, but we don't to that anymore. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
In order for memory locking to work, the hard limit on memory locking (and usage) has to be set appropriately by the user. The documentation mentions the requirement already: with this patch, it's going to be enforced by runtime checks as well, by forbidding a non-compliant guest from being defined as well as edited and started. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316774
-
- 07 2月, 2017 5 次提交
-
-
由 Michal Privoznik 提交于
When working with symlinks it is fairly easy to get into a loop. Don't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Similarly to one of the previous commits, we need to deal properly with symlinks in hotplug case too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When working with symlinks it is fairly easy to get into a loop. Don't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Imagine you have a disk with the following source set up: /dev/disk/by-uuid/$uuid (symlink to) -> /dev/sda After cbc45525 the transitive end of the symlink chain is created (/dev/sda), but we need to create any item in chain too. Others might rely on that. In this case, /dev/disk/by-uuid/$uuid comes from domain XML thus it is this path that secdriver tries to relabel. Not the resolved one. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
After previous commit this has become redundant step. Also setting up devices in namespace and setting their label later on are two different steps and should be not done at once. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 26 1月, 2017 2 次提交
-
-
由 Michal Privoznik 提交于
Not only we should set the MTU on the host end of the device but also let qemu know what MTU did we set. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far we allow to set MTU for libvirt networks. However, not all domain interfaces have to be plugged into a libvirt network and even if they are, they might want to have a different MTU (e.g. for testing purposes). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 22 1月, 2017 1 次提交
-
-
由 Chen Hanxiao 提交于
We lacked of timestamp in tainting of guests log, which bring troubles for finding guest issues: such as whether a guest powerdown caused by qemu-monitor-command or others issues inside guests. If we had timestamp in tainting of guests log, it would be helpful when checking guest's /var/log/messages. Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
- 20 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Based on work of Mehdi Abaakouk <sileht@sileht.net>. When parsing vhost-user interface XML and no ifname is found we can try to fill it in in post parse callback. The way this works is we try to make up interface name from given socket path and then ask openvswitch whether it knows the interface. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 17 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1413922 While all the code that deals with qemu namespaces correctly detects whether we are running as root (and turn into NO-OP for qemu:///session) the actual unshare() call is not guarded with such check. Therefore any attempt to start a domain under qemu:///session shall fail as unshare() is reserved for root. The fix consists of moving unshare() call (for which we have a wrapper called virProcessSetupPrivateMountNS) into qemuDomainBuildNamespace() where the proper check is performed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Tested-by: NRichard W.M. Jones <rjones@redhat.com>
-
- 13 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
When creating new /dev/* for qemu, we do chown() and copy ACLs to create the exact copy from the original /dev. I though that copying SELinux labels is not necessary as SELinux will chose the sane defaults. Surprisingly, it does not leaving namespace with the following labels: crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 random crw-------. root root system_u:object_r:tmpfs_t:s0 rtc0 drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0 shm crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 urandom As a result, domain is unable to start: error: internal error: process exited while connecting to monitor: Error in GnuTLS initialization: Failed to acquire random data. qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS library: Failed to acquire random data. The solution is to copy the SELinux labels as well. Reported-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 1月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
So far the decision whether /dev/* entry is created in the qemu namespace is really simple: does the path starts with "/dev/"? This can be easily fooled by providing path like the following (for any considered device like disk, rng, chardev, ..): /dev/../var/lib/libvirt/images/disk.qcow2 Therefore, before making the decision the path should be canonicalized. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far the namespaces were turned on by default unconditionally. For all non-Linux platforms we provided stub functions that just ignored whatever namespaces setting there was in qemu.conf and returned 0 to indicate success. Moreover, we didn't really check if namespaces are available on the host kernel. This is suboptimal as we might have ignored user setting. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is a simple wrapper over mount(). However, not every system out there is capable of moving a mount point. Therefore, instead of having to deal with this fact in all the places of our code we can have a simple wrapper and deal with this fact at just one place. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Due to a copy-paste error, the debug message reads: Setting up disks It should have been: Setting up inputs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
This function is used only from code compiled on Linux. Therefore on non-Linux platforms it triggers compilation error: ../../src/qemu/qemu_domain.c:209:1: error: unused function 'qemuDomainGetPreservedMounts' [-Werror,-Wunused-function] Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 1月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
After previous commits, this function is no longer needed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, there is no need to create /var/lib/libvirt/$domain.* directories in CreateNamespace(). It is sufficient to create them as soon as we need them which is in BuildNamespace. This way we don't leave them around for the whole lifetime of domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The c1140eb9 got me thinking. We don't want to special case /dev in qemuDomainGetPreservedMounts(), but in all other places in the code we special case it anyway. I mean, /var/run/libvirt/$domain.dev path is constructed separately just so that it is not constructed here. It makes only a little sense (if any at all). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
If something goes wrong in this function we try a rollback. That is unlink all the directories we created earlier. For some weird reason unlink() was called instead of rmdir(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 05 1月, 2017 1 次提交
-
-
由 Martin Kletzander 提交于
Just so it doesn't bite us in the future, even though it's unlikely. And fix the comment above it as well. Commit e08ee7cd took the info from the function it's calling, but that was lie itself in the first place. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-