[libvirt] [PATCH] doc: Add statment about permissions needed to do a core dump
Documentation did not specify, that some permissions are required on target path for coredump for the user running the hypervisor. --- src/libvirt.c | 4 +++- tools/virsh.pod | 3 +++ 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index c32c7a6..ee88d87 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -2777,7 +2777,9 @@ error: * * This method will dump the core of a domain on a given file for analysis. * Note that for remote Xen Daemon the file path will be interpreted in - * the remote host. + * the remote host. Hypervisors may require execute and/or write permissions + * for destination path specified by argument @to for user running the + * hypervisor. * * If @flags includes VIR_DUMP_CRASH, then leave the guest shut off with * a crashed state after the dump completes. If @flags includes diff --git a/tools/virsh.pod b/tools/virsh.pod index e82567d..ba7af15 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -621,6 +621,9 @@ rather than merely left in a paused state. If I<--bypass-cache> is specified, the save will avoid the file system cache, although this may slow down the operation. +NOTE: Some hypervisors may require execute and/or write permissions on +I<corefilepath> for user running the hypervisor. + =item B<dumpxml> I<domain-id> [I<--inactive>] [I<--security-info>] [I<--update-cpu>] -- 1.7.3.4
On 09/15/2011 02:27 AM, Peter Krempa wrote:
Documentation did not specify, that some permissions are required on target path for coredump for the user running the hypervisor. --- src/libvirt.c | 4 +++- tools/virsh.pod | 3 +++ 2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c index c32c7a6..ee88d87 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -2777,7 +2777,9 @@ error: * * This method will dump the core of a domain on a given file for analysis. * Note that for remote Xen Daemon the file path will be interpreted in - * the remote host. + * the remote host. Hypervisors may require execute and/or write permissions + * for destination path specified by argument @to for user running the + * hypervisor.
That sounds wrong to me. We already have the ability to relabel files and directories so that qemu can access them; why should the core file be any different than any other image file where libvirt is able to grant proper permissions? Also, the wording is misleading - you are talking about 'search' permissions on the parent directories, not 'execute' on the file itself (the x bit is double-duty, execute for files and search for directories). So we should not be mentioning execute permissions. If we can't fix the real bug (that is, that libvirt is not granting proper permissions to qemu to be able to create the core dump), then I'd favor wording more like: Hypervisors may require the user to manually ensure proper permissions on the file named by @to. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Dňa 15.9.2011 21:32, Eric Blake wrote / napísal(a):
That sounds wrong to me. We already have the ability to relabel files and directories so that qemu can access them; why should the core file be any different than any other image file where libvirt is able to grant proper permissions? Well, I looked through the code and it seemed to me that it's done that way. I couldn't reproduce that because my qemu runs with uid 0.
Also, the wording is misleading - you are talking about 'search' permissions on the parent directories, not 'execute' on the file itself (the x bit is double-duty, execute for files and search for directories). So we should not be mentioning execute permissions. If we can't fix the real bug (that is, that libvirt is not granting proper permissions to qemu to be able to create the core dump), then I'd favor wording more like:
Yes, search permission. I somehow still call it execute even on directories even though I am aware of the difference :/ ... I'll fix it.
Hypervisors may require the user to manually ensure proper permissions on the file named by @to.
That's elegant, thanks :). Peter
participants (2)
-
Eric Blake -
Peter Krempa