- 14 2月, 2013 12 次提交
-
-
由 Laine Stump 提交于
This is an interim measure to make sure everything still works in this order. The next step will be to perform capabilities drop and setuid/gid as a single operation (which is the only way to keep any capabilities when switching to a non-root uid).
-
由 Laine Stump 提交于
The qemu driver had been calling virSecurityManagerSetProcessLabel() from a "pre-exec hook" function that is run after the child is forked, but before exec'ing qemu. This is problematic because the uid and gid of the child are set by the security driver, but capabilities are dropped by virCommand - such separation doesn't work; the two operations must be done together or the capabilities do not transfer properly to the child process. This patch switches to using virSecurityManagerSetChildProcessLabel(), which is called prior to virCommandRun() (rather than being called *during* virCommandrun() by the hook function), and doesn't set the UID/GID/security label directly, but instead merely informs virCommand what it should set them all to when the time is appropriate. This lets virCommand choose to do the uid/gid and caps dropping all at the same time if it wants (it does *want* to, but isn't doing so yet; that's for an upcoming patch).
-
由 Laine Stump 提交于
The existing virSecurityManagerSetProcessLabel() API is designed so that it must be called after forking the child process, but before exec'ing the child. Due to the way the virCommand API works, that means it needs to be put in a "hook" function that virCommand is told to call out to at that time. Setting the child process label is a basic enough need when executing any process that virCommand should have a method of doing that. But virCommand must be told what label to set, and only the security driver knows the answer to that question. The new virSecurityManagerSet*Child*ProcessLabel() API is the way to transfer the knowledge about what label to set from the security driver to the virCommand object. It is given a virCommandPtr, and each security driver calls the appropriate virCommand* API to tell virCommand what to do between fork and exec. 1) in the case of the DAC security driver, it calls virCommandSetUID/GID() to set a uid and gid that must be set for the child process. 2) for the SELinux security driver, it calls virCommandSetSELinuxLabel() to save a copy of the char* that will be sent to setexeccon_raw() *after forking the child process*. 3) for the AppArmor security drivers, it calls virCommandSetAppArmorProfile() to save a copy of the char* that will be sent to aa_change_profile() *after forking the child process*. With this new API in place, we will be able to remove virSecurityManagerSetProcessLabel() from any virCommand pre-exec hooks. (Unfortunately, the LXC driver uses clone() rather than virCommand, so it can't take advantage of this new security driver API, meaning that we need to keep around the older virSecurityManagerSetProcessLabel(), at least for now.)
-
由 Laine Stump 提交于
virCommand gets two new APIs: virCommandSetSELinuxLabel() and virCommandSetAppArmorProfile(), which both save a copy of a null-terminated string in the virCommand. During virCommandRun, if the string is non-NULL and we've been compiled with AppArmor and/or SELinux security driver support, the appropriate security library function is called for the child process, using the string that was previously set. In the case of SELinux, setexeccon_raw() is called, and for AppArmor, aa_change_profile() is called. This functionality has been added so that users of virCommand can use the upcoming virSecurityManagerSetChildProcessLabel() prior to running a child process, rather than needing to setup a hook function to be called (and in turn call virSecurityManagerSetProcessLabel()) *during* the setup of the child process.
-
由 Laine Stump 提交于
This makes it simpler to include the necessary system security driver libraries for a particular system. For this patch, several existing conditional sections from the Makfile were replaced; I'll later be adding SECDRIVER_LIBS to libvirt_util_la_LIBADD, because vircommand.c will be calling a function from $securitylib.
-
由 Laine Stump 提交于
-
由 Laine Stump 提交于
Setting the uid/gid of the child process was the only thing done by the hook function in this case, and that can now be done more simply with virCommandSetUID/GID.
-
由 Laine Stump 提交于
Rather than treating uid:gid of 0:0 as a NOP, we blindly pass that through to the lower layers. However, we *do* check for a requested value of "-1" to mean "don't change this setting". setregid() and setreuid() already interpret -1 as a NOP, so this is just an optimization, but we are also calling getpwuid_r and initgroups, and it's unclear what the former would do with a uid of -1.
-
由 Laine Stump 提交于
If a uid and/or gid is specified for a command, it will be set just after the user-supplied post-fork "hook" function is called. The intent is that this can replace user hook functions that set uid/gid. This moves the setting of uid/gid and dropping of capabilities closer to each other, which is important since the two should really be done at the same time (libcapng provides a single function that does both, which we will be unable to use, but want to mimic as closely as possible).
-
由 Laine Stump 提交于
-
由 Laine Stump 提交于
All args except "cmd" in the call to virExec are now redundant, since they can all be found in cmd, so remove the args and reference the data directly in cmd. One exception to this is that "infd" was being modified within virExec, and modifying the original in cmd caused make check failures, so cmd->infd is copied to a local, and the local is used during virExec().
-
由 Laine Stump 提交于
virExecWithHook is only called from one place, so it always has the same "hook" function (virHookCommand), and the data sent to that function is always a virCommandPtr, so eliminate the function and generic data from the arglist, and replace it with "virCommandPtr cmd". The call to (hook)(data) is replaced with "virHookCommand(cmd)". Finally, virExecWithHook is renamed to virExec. Indentation has been updated only for code that will remain after the next patch, which will remove all other args to virExec (since they are now redundant, as they're all members of virCommandPtr).
-
- 13 2月, 2013 18 次提交
-
-
由 Daniel P. Berrange 提交于
With the majority of fields in the virQEMUDriverPtr struct now immutable or self-locking, there is no need for practically any methods to be using the QEMU driver lock. Only a handful of helper APIs in qemu_conf.c now need it
-
由 Michal Privoznik 提交于
Currently, if a command wants to do asynchronous IO, a callback is registered in the libvirtd eventloop to handle writes and reads. However, there's a race in virCommandWait. The eventloop may already be executing the callback, while virCommandWait is mangling internal state of virCommand. To deal with it, we need to either introduce locking or spawn a separate thread where we poll() on stdio from child. The former, however, requires to unlock all mutexes held, as the event loop may execute other callbacks which tries to lock one of the mutexes, deadlock and thus never wake us up. So it's safer to spawn a separate thread.
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-
由 Eric Blake 提交于
Commit 8b55992f added some Coverity comments to silence what was a real bug in the code. Since then, we've had a miserable run of trying to fix the underlying problem (commits c059cdea and ba5193c8), and still have a problem on 32-bit machines. This fixes the problem for once and for all, by realizing that on older xen, cpumap_t is identical to uint64_t, and using the new virendian.h to do the transformation from the API (documented to be little-endian) to the host structure. * src/xen/xen_hypervisor.c (virXen_setvcpumap): Do the conversion correctly. Finally.
-
由 Eric Blake 提交于
This makes code easier to read, by avoiding lines longer than 80 columns and removing the repetition from the callers. * src/util/virstoragefile.c (qedGetHeaderUL, qedGetHeaderULL): Delete in favor of more generic macros. (qcow2GetBackingStoreFormat, qcowXGetBackingStore) (qedGetBackingStore, virStorageFileMatchesVersion) (virStorageFileGetMetadataInternal): Use new macros. * src/cpu/cpu_x86.c (x86VendorLoad): Likewise.
-
由 Eric Blake 提交于
We have several cases where we need to read endian-dependent data regardless of host endianness; rather than open-coding these call sites, it will be nicer to funnel things through a macro. The virendian.h file can be expanded to add writer functions, and/or 16-bit access patterns, if needed. Also, if we need to turn things into a function to avoid multiple evaluations of buf, that can be done later. But for now, a macro worked. * src/util/virendian.h: New file. * src/Makefile.am (UTIL_SOURCES): Ship it. * tests/virendiantest.c: New test. * tests/Makefile.am (test_programs, virendiantest_SOURCES): Run the test. * .gitignore: Ignore built file.
-
- 12 2月, 2013 10 次提交
-
-
由 Daniel P. Berrange 提交于
When removing a VM from the virDomainObjListPtr, we must not be holding the VM lock while acquiring the list lock. Re-order code to ensure that we can release the VM lock early.
-
由 Daniel P. Berrange 提交于
The hook scripts used by virCommand must be careful wrt accessing any mutexes that may have been held by other threads in the parent process. With the recent refactoring there are 2 potential flaws lurking, which will become real deadlock bugs once the global QEMU driver lock is removed. Remove use of the QEMU driver lock from the hook function by passing in the 'virQEMUDriverConfigPtr' instance directly. Add functions to the virSecurityManager to be invoked before and after fork, to ensure the mutex is held by the current thread. This allows it to be safely used in the hook script in the child process. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Eric Blake 提交于
On RHEL 5, I got: security/security_selinux.c: In function 'getContext': security/security_selinux.c:971: warning: unused parameter 'mgr' [-Wunused-parameter] * src/security/security_selinux.c (getContext): Mark potentially unused parameter.
-
由 Viktor Mihajlovski 提交于
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>
-
由 Viktor Mihajlovski 提交于
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>
-
由 Eric Blake 提交于
'make check' has been failing on VPATH builds since commit 907a39e7. The tests already had magic for munging path names, but were munging to the wrong location, thus working only on an in-tree build. * tests/securityselinuxlabeltest.c (testSELinuxMungePath): Munge to correct path.
-
由 Eric Blake 提交于
* docs/news.html.in: Use correct release year.
-
由 Laine Stump 提交于
Broken by incorrect formatting / spelling of remote_nonnull in commit 39758e75
-
由 Guido Günther 提交于
This makes sure we don't regress to old style classes
-
由 John Ferlan 提交于
Adjustment for 'c059cdea' due to older compiler complaint about pm not being initialized even though the j&7 == 0 does the trick.
-