- 19 4月, 2013 2 次提交
-
-
由 Paolo Bonzini 提交于
When running unprivileged, virSetUIDGIDWithCaps will fail because it tries to add the requested capabilities to the permitted and effective sets. Detect this case, and invoke the child with cleared permitted and effective sets. If it is a setuid program, it will get them. Some care is needed also because you cannot drop capabilities from the bounding set without CAP_SETPCAP. Because of that, ignore errors from setting the bounding set. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
The need_prctl variable is not really needed. If it is false, capng_apply will be called twice with the same set, causing a little extra work but no problem. This keeps the code a bit simpler. It is also clearer to invoke capng_apply(CAPNG_SELECT_BOUNDS) separately, to make sure it is done while we have CAP_SETPCAP. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 17 4月, 2013 1 次提交
-
-
由 Osier Yang 提交于
The recent qemu requires "0x" prefix for the disk wwn, this patch changes virValidateWWN to allow the prefix, and prepend "0x" if it's not specified. E.g. qemu-kvm: -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\ drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,wwn=6000c60016ea71ad: Property 'scsi-hd.wwn' doesn't take value '6000c60016ea71ad' Though it's a qemu regression, but it's nice to allow the prefix, and doesn't hurt for us to always output "0x".
-
- 08 4月, 2013 2 次提交
-
-
由 Osier Yang 提交于
This finds the parent for vHBA by iterating over all the HBA which supports vport_ops capability on the host, and return the first one which is online, not saturated (vports in use is less than max_vports).
-
由 Osier Yang 提交于
The helper iterates over sysfs, to find out the matched scsi host name by comparing the wwnn,wwpn pair. It will be used by checkPool and refreshPool of storage scsi backend. New helper getAdapterName is introduced in storage_backend_scsi.c, which uses the new util helper virGetFCHostNameByWWN to get the fc_host adapter name.
-
- 28 3月, 2013 2 次提交
-
-
由 Michal Privoznik 提交于
There has been a typo in virIsCapbleVport function name.
-
由 Osier Yang 提交于
--- Pushed under build-breaker rule.
-
- 25 3月, 2013 4 次提交
-
-
由 Osier Yang 提交于
The string written to "vport_create" or "vport_delete" should be "wwnn:wwpn", but not "wwpn:wwnn".
-
由 Osier Yang 提交于
This abstracts nodeDeviceVportCreateDelete as an util function virManageVport, which can be further used by later storage patches (to support persistent vHBA, I don't want to create the vHBA using the public API, which is not good).
-
由 Osier Yang 提交于
This adds two util functions (virIsCapableFCHost and virIsCapableVport), and rename helper check_fc_host_linux as detect_scsi_host_caps, check_capable_vport_linux is removed, as it's abstracted to the util function virIsCapableVport. detect_scsi_host_caps nows detect both the fc_host and vport_ops capabilities. "stat(2)" is replaced with "access(2)" for saving. * src/util/virutil.h: - Declare virIsCapableFCHost and virIsCapableVport * src/util/virutil.c: - Implement virIsCapableFCHost and virIsCapableVport * src/node_device/node_device_linux_sysfs.c: - Remove check_capable_vport_linux - Rename check_fc_host_linux as detect_scsi_host_caps, and refactor it a bit to detect both fc_host and vport_os capabilities * src/node_device/node_device_driver.h: - Change/remove the related declarations * src/node_device/node_device_udev.c: (Use detect_scsi_host_caps) * src/node_device/node_device_hal.c: (Likewise) * src/node_device/node_device_driver.c (Likewise)
-
由 Osier Yang 提交于
"open_wwn_file" in node_device_linux_sysfs.c is redundant, on one hand it duplicates work of virFileReadAll, on the other hand, it's waste to use a function for it, as there is no other users of it. So I don't see why the file opening work cannot be done in "read_wwn_linux". "read_wwn_linux" can be abstracted as an util function. As what all it does is to read the sysfs entry. So this patch removes "open_wwn_file", and abstract "read_wwn_linux" as an util function "virReadFCHost" (a more general name, because after changes, it can read each of the fc_host entry now). * src/util/virutil.h: (Declare virReadFCHost) * src/util/virutil.c: (Implement virReadFCHost) * src/node_device/node_device_linux_sysfs.c: (Remove open_wwn_file, and read_wwn_linux) src/node_device/node_device_driver.h: (Remove the declaration of read_wwn_linux, and the related macros) src/libvirt_private.syms: (Export virReadFCHost)
-
- 16 3月, 2013 1 次提交
-
-
由 Eric Blake 提交于
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.
-
- 15 3月, 2013 1 次提交
-
-
由 Laine Stump 提交于
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).
-
- 06 3月, 2013 1 次提交
-
-
由 Guannan Ren 提交于
A value which is equal to a integer maximum such as LLONG_MAX is a valid integer value. The patch fix the following error: 1, virsh memtune vm --swap-hard-limit -1 2, virsh start vm In debug mode, it shows error like: virScaleInteger:1813 : numerical overflow:\ value too large: 9007199254740991KiB
-
- 25 2月, 2013 2 次提交
-
-
由 Philipp Hahn 提交于
uid_t and gid_t are opaque types, ranging from s32 to u32 to u64. Explicitly cast the magic -1 to the appropriate type. Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-
由 Philipp Hahn 提交于
The uid_t|gid_t values are explicitly casted to "unsigned long", but the printf() still used "%d", which is for signed values. Change the format to "%u". Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-
- 16 2月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Commits 20253560 and ba72cb12 introduced typos. * src/util/virpci.c (virPCIIsVirtualFunction) [!__linux__]: Fix function name. * src/util/virutil.c (virGetDeviceID): Fix attribute spelling.
-
- 14 2月, 2013 2 次提交
-
-
由 Laine Stump 提交于
Normally when a process' uid is changed to non-0, all the capabilities bits are cleared, even those explicitly set with calls to capng_update()/capng_apply() made immediately before setuid. And *after* the process' uid has been changed, it no longer has the necessary privileges to add capabilities back to the process. In order to set a non-0 uid while still maintaining any capabilities bits, it is necessary to either call capng_change_id() (which unfortunately doesn't currently call initgroups to setup auxiliary group membership), or to perform the small amount of calisthenics contained in the new utility function virSetUIDGIDWithCaps(). Another very important difference between the capabilities setting/clearing in virSetUIDGIDWithCaps() and virCommand's virSetCapabilities() (which it will replace in the next patch) is that the new function properly clears the capabilities bounding set, so it will not be possible for a child process to set any new capabilities. A short description of what is done by virSetUIDGIDWithCaps(): 1) clear all capabilities then set all those desired by the caller (in capBits) plus CAP_SETGID, CAP_SETUID, and CAP_SETPCAP (which is needed to change the capabilities bounding set). 2) call prctl(), telling it that we want to maintain current capabilities across an upcoming setuid(). 3) switch to the new uid/gid 4) again call prctl(), telling it we will no longer want capabilities maintained if this process does another setuid(). 5) clear the capabilities that we added to allow us to setuid/setgid/change the bounding set (unless they were also requested by the caller via the virCommand API). Because the modification/maintaining of capabilities is intermingled with setting the uid, this is necessarily done in a single function, rather than having two independent functions. Note that, due to the way that effective capabilities are computed (at time of execve) for a process that has uid != 0, the *file* capabilities of the binary being executed must also have the desired capabilities bit(s) set (see "man 7 capabilities"). This can be done with the "filecap" command. (e.g. "filecap /usr/bin/qemu-kvm sys_rawio").
-
由 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.
-
- 22 1月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
Currently, whenever somebody calls saferead() on nonblocking FD (safewrite() is totally interchangeable for purpose of this message) he might get wrong return value. For instance, in the first iteration some data is read. The number of bytes read is stored into local variable 'nread'. However, in next iterations we can get -1 from read() with errno == EAGAIN, in which case the -1 is returned despite fact some data has already been read. So the caller gets confused. Bare read() should be used for nonblocking FD.
-
- 14 1月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 11 1月, 2013 1 次提交
-
-
由 Eric Blake 提交于
There's no need to do lots of readlink() calls to canonicalize a name if we're only going to use stat() on it, since stat() already chases symlinks. * src/util/virutil.c (virGetDeviceID): Let stat() do the symlink chasing.
-
- 07 1月, 2013 2 次提交
-
-
由 Osier Yang 提交于
This ignores the default "filtered" if unpriv_sgio is not supported by kernel, but for explicit request "filtered", it error out for domain starting.
-
由 Osier Yang 提交于
"virGetDeviceID" could be used across the sources, but it doesn't relate with this series, and could be done later. * src/util/virutil.h: (Declare virGetDeviceID, and vir{Get,Set}DeviceUnprivSGIO) * src/util/virutil.c: (Implement virGetDeviceID and vir{Get,Set}DeviceUnprivSGIO) * src/libvirt_private.syms: Export private symbols of upper helpers
-
- 21 12月, 2012 8 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 12 12月, 2012 2 次提交
-
-
由 Peter Krempa 提交于
I didn't notice the extra "does" in the previous patch. Remove it.
-
由 Peter Krempa 提交于
This patch gets rid of the undeterministic error reporting code done on return values of get(pw|gr)nam_r. With this patch, if the group record is not returned by the corresponding function this error is not considered fatal even if errno != 0. The error is logged in such case.
-
- 07 12月, 2012 3 次提交
-
-
由 Osier Yang 提交于
QEMU supports setting vendor and product strings for disk since 1.2.0 (only scsi-disk, scsi-hd, scsi-cd support it), this patch exposes it with new XML elements <vendor> and <product> of disk device.
-
由 Christophe Fergeau 提交于
virGetGroupIDByName is documented as returning 1 if the groupname cannot be found. getgrnam_r is documented as returning: « 0 or ENOENT or ESRCH or EBADF or EPERM or ... The given name or gid was not found. » and that: « The formulation given above under "RETURN VALUE" is from POSIX.1-2001. It does not call "not found" an error, hence does not specify what value errno might have in this situation. But that makes it impossible to recognize errors. One might argue that according to POSIX errno should be left unchanged if an entry is not found. Experiments on various UNIX-like systems shows that lots of different values occur in this situation: 0, ENOENT, EBADF, ESRCH, EWOULDBLOCK, EPERM and probably others. » virGetGroupIDByName returns an error when the return value of getgrnam_r is non-0. However on my RHEL system, getgrnam_r returns ENOENT when the requested user cannot be found, which then causes virGetGroupID not to behave as documented (it returns an error instead of falling back to parsing the passed-in value as an gid). This commit makes virGetGroupIDByName only report an error when errno is set to one of the values in the posix description of getgrnam_r (which are the same as the ones described in the manpage on my system).
-
由 Christophe Fergeau 提交于
virGetUserIDByName is documented as returning 1 if the username cannot be found. getpwnam_r is documented as returning: « 0 or ENOENT or ESRCH or EBADF or EPERM or ... The given name or uid was not found. » and that: « The formulation given above under "RETURN VALUE" is from POSIX.1-2001. It does not call "not found" an error, hence does not specify what value errno might have in this situation. But that makes it impossible to recognize errors. One might argue that according to POSIX errno should be left unchanged if an entry is not found. Experiments on various UNIX-like systems shows that lots of different values occur in this situation: 0, ENOENT, EBADF, ESRCH, EWOULDBLOCK, EPERM and probably others. » virGetUserIDByName returns an error when the return value of getpwnam_r is non-0. However on my RHEL system, getpwnam_r returns ENOENT when the requested user cannot be found, which then causes virGetUserID not to behave as documented (it returns an error instead of falling back to parsing the passed-in value as an uid). This commit makes virGetUserIDByName only report an error when errno is set to one of the values in the posix description of getpwnam_r (which are the same as the ones described in the manpage on my system).
-
- 23 11月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
The docs for virDiskNameToIndex claim it ignores partition numbers. In actual fact though, a code ordering bug means that a partition number will cause the code to accidentally multiply the result by 26. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 02 11月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
The libvirt coding standard is to use 'function(...args...)' instead of 'function (...args...)'. A non-trivial number of places did not follow this rule and are fixed in this patch. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 22 10月, 2012 1 次提交
-
-
由 Cole Robinson 提交于
-