- 18 9月, 2018 14 次提交
-
-
由 Michal Privoznik 提交于
Lock all the paths we want to relabel to mutually exclude other libvirt daemons. The only hitch here is that directories can't be locked. Therefore, when relabeling a directory do not lock it (this happens only when setting up some domain private paths anyway, e.g. huge pages directory). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Firstly, the message that says we're setting uid:gid shouldn't be called from virSecurityDACSetOwnershipInternal() because virSecurityDACRestoreFileLabelInternal() is calling it too. Secondly, there are places between us reporting label restore and us actually doing it where we can quit. Don't say we're doing something until we are actually about to do it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
So far the whole transaction handling is done virSecurityDACSetOwnershipInternal(). This needs to change for the sake of security label remembering and locking. Otherwise we would be locking a path when only appending it to transaction list and not when actually relabeling it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Two new APIs are added so that security driver can lock and unlock paths it wishes to touch. These APIs are not for other drivers to call but security drivers (DAC and SELinux). That is the reason these APIs are not exposed through our libvirt_private.syms file. Three interesting things happen in this commit. The first is the global @lockManagerMutex. Unfortunately, this has to exist so that there is only one thread talking to virtlockd at a time. If there were more threads and one of them closed the connection prematurely, it would cause virtlockd killing libvirtd. Instead of complicated code that would handle that, let's have a mutex and keep the code simple. The second interesting thing is keeping connection open between lock and unlock API calls. This is achieved by duplicating client FD and keeping it open until unlock is called. This trick is used by regular disk content locking code when the FD is leaked to qemu. Finally, the third thing is polling implemented at client side. Since virtlockd has only one thread that handles locking requests, all it can do is either acquire lock or error out. Therefore, the polling has to be implemented in client. The polling is capped at 60 second timeout, which should be plenty since the metadata lock is held only for a fraction of a second. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Now that we know what metadata lock manager user wishes to use we can load it when initializing security driver. This is achieved by adding new argument to virSecurityManagerNewDriver() and subsequently to all functions that end up calling it. The cfg.mk change is needed in order to allow lock_manager.h inclusion in security driver without 'syntax-check' complaining. This is safe thing to do as locking APIs will always exist (it's only backend implementation that changes). However, instead of allowing the include for all other drivers (like cpu, network, and so on) allow it only for security driver. This will still trigger the error if including from other drivers. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This config option allows users to set and enable lock manager for domain metadata. The lock manager is going to be used by security drivers to serialize each other when changing a file ownership or changing the SELinux label. The only supported lock manager is 'lockd' for now. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
In some cases we might want to not load the lock driver config. Alter virLockManagerPluginNew() and the lock drivers to cope with this fact. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Soon there will be a virtlockd client that wants to either lock all the resources or none (in order to avoid virtlockd killing the client on connection close). Because on the RPC layer we can only acquire one resource at a time, we have to perform a rollback once we hit a resource that can't be acquired. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This is a new type of object that lock drivers can handle. Currently, it is supported by lockd driver only. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
The fact whether domain has or doesn't have RW disks is specific to VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN and therefore should reside in union specific to it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
We will want virtlockd to lock files on behalf of libvirtd and not qemu process, because it is libvirtd that needs an exclusive access not qemu. This requires new lock context. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This flag causes virtlockd to use different offset when locking the file. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
So far the virLockSpaceAcquireResource() locks the first byte in the underlying file. But caller might want to lock other range. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Erik Skultety 提交于
From time to time it's handy to jump directly to a function prototype in a header. However, generating tags for headers is disabled by default in ctags, let's enable it by using --c-kinds=+p. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 17 9月, 2018 19 次提交
-
-
由 Andrea Bolognani 提交于
The directory has been renamed in 56299084, but a reference to it was not updated at the same time, causing 'make dist' to fail ever since. Fix it. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
The file being present doesn't necessarily mean anything these days, as it's created independently of whether the kvm module has been loaded[1]; moreover, we're already gathering all the information we need through QMP, so poking the filesystem at all is entirely unnecessary. [1] https://github.com/systemd/systemd/commit/d35d6249d5a7ed3228Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
This capability is documented as having one meaning (whether KVM is enabled by default) but is actually assigned two other meanings over its life: whether the query-kvm QMP command is available at first, and later on whether KVM is usable / was used during probing. Since the query-kvm QMP command was available in 1.5.0, we can avoid probing for it; additionally, we can simplify the logic by setting the flag when it applies instead of initially setting it and then clearing it when it doesn't. The flag's description is also updated to reflect reality. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
A side effect of recent changes is that we would always try to regenerate the capabilities cache for non-native QEMU binaries based on /dev/kvm availability, which is of course complete nonsense. Make sure that doesn't happen. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
It was already available in 1.5.0. Moreover, we're not even formatting it on the QEMU command line, ever: we just use it as part of some logic that decides whether KVM support should be advertised, and as it turns out that logic is actually buggy and dropping this capability fixes it. https://bugzilla.redhat.com/show_bug.cgi?id=1628469Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
More specifically, everything that's tested by qemucapabilities now goes through qemucaps2xml as well. Ideally we'll rewrite both so that listing all test cases is unnecessary and they get picked up automatically by listing the contents of the input directory instead, but that's a refactor for another day :) Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
While qemucaps2xml has a meager two test cases to its name, we have plenty of data from qemucapabilities which is taken from actual QEMU binaries, covers pretty much all supported QEMU versions and architectures and is even in the right format already! Rewrite qemucaps2xml so that it uses qemucapabilities data as input. Right now we have a single test case, but we're going to add a lot more next. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Shi Lei 提交于
This patch add syntax-check rule for incorrect indentation and blank first line in function body by changing check-spacing.pl. For efficiency, it only checks the first line of function body. But it's enough for most cases. Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
由 Shi Lei 提交于
Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
由 Shi Lei 提交于
Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
由 Shi Lei 提交于
Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
由 Shi Lei 提交于
Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
由 Shi Lei 提交于
Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
由 Michal Privoznik 提交于
Now that committing transactions using pid == -1 means that we're not fork()-ing to run the transaction in a specific namespace, we can utilize the transaction processing semantics in order to start, run a or multiple commands, and then commit the transaction without being concerned with other interactions or transactions interrupting the processing. This will eventually allow us to have a single place where all the paths can be locked, followed by relabeling and unlocking again. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
It will be desirable to run transactions more often than we currently do. Even if the domain we're relabeling the paths for does not run in a namespace. If that's the case, there is no need to fork() as we are already running in the right namespace. To differentiate whether transaction code should fork() or not the @pid argument now accepts -1 (which means do not fork). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
In the future, the transactions are not going to be optional and they will be run regardless of domain using namespace to collect list of paths to be relabeled. To make sure there won't be an API that goes behind transaction code back update the comment that serves as decision manual whether an API must be fully implemented or plain #define is sufficient. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Even though the current use of the functions does not require full implementation with transactions (none of the callers passes a path somewhere under /dev), it doesn't hurt either. Moreover, in future patches the paradigm is going to shift so that any API that touches a file is required to use transactions. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Even though the current use of the function does not require full implementation with transactions (none of the callers pass a path somewhere under /dev), it doesn't hurt either. Moreover, in future patches the paradigm is going to shift so that any API that touches a file is required to use transactions. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Andrea Bolognani 提交于
Functions that deal with virPCIDeviceAddress exclusively belong to util/virpci. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 15 9月, 2018 2 次提交
-
-
由 Jim Fehlig 提交于
Signed-off-by: NJim Fehlig <jfehlig@suse.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jim Fehlig 提交于
Currently the libxl driver claims support for Xen >= 4.4, but Xen 4.4 and 4.5 are no longer supported upstream. Let's increase the minimum supported Xen version to 4.6 and change the defined LIBXL_API_VERSION to 0x040500, which is the API version defined when Xen 4.6 was released. Since Xen 4.6 contains a pkgconfig file, drop the now unused code that falls back to using LIBVIRT_CHECK_LIB in the absence of pkgconfig file. In addition, bumping the LIBXL_API_VERSION required adjusting the calls to libxl_set_vcpuaffinity to account for the extra parameter in the 0x040500 version of the API. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 14 9月, 2018 2 次提交
-
-
由 Lin Ma 提交于
commit b00c9c39 removed the label end_of_netlink_messages and 'return table' statement, It causes the function virArpTableGet doesn't return a proper virArpTable pointer. How to reproduce: # virsh domiflist sles12sp3 Interface Type Source Model MAC ------------------------------------------------------- vnet0 network default virtio 52:54:00:cd:02:e6 # virsh domifaddr sles12sp3 --source arp error: Failed to query for interfaces addresses error: An error occurred, but the cause is unknown It seems that the "if (nh->nlmsg_type == NLMSG_DONE)" statement won't be meted. So this patch adds 'return table' when the iterations of nlmsghdr for loop is over. Signed-off-by: NLin Ma <lma@suse.com> Reviewed-by: NChen Hanxiao <chenhanxiao@gmail.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 13 9月, 2018 3 次提交
-
-
由 Martin Kletzander 提交于
It is not a problem at all if the `tss` user/group does not exist, the code fallbacks to the `root` user/group. However we report a warning for no reason on every start-up. Fix this by checking if the user/group actually exists. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Instead of duplicating the code from virGet{User,Group}IDByName(), which are static anyway, extend those functions to accept NULL pointers for the result and a boolean for controlling the error reporting. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Otherwise after libvirtd restart we come back to issues fixed by introducing this flag in [1]. [1] 61a0026a : qemu: Fix xml dump of autogenerated websocket Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-