search for: chown_for_libvirt_rhbz_1045069

Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we suppress the exception (we log it in verbose mode only, even). That's not proved helpful: it almost certainly leads to later errors, but those errors are less clear than the original (suppressed) exception. Namely, the user sees something like > Failed...

On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote: > Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we > suppress the exception (we log it in verbose mode only, even). > > That's not proved helpful: it almost certainly leads to later errors, but > those errors are less clear than the original (suppressed) exception. > Namely, the user sees so...

On 6/29/23 14:54, Richard W.M. Jones wrote: > On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote: >> Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we >> suppress the exception (we log it in verbose mode only, even). >> >> That's not proved helpful: it almost certainly leads to later errors, but >> those errors are less clear than the original (suppressed) exception. >> Namel...

On Thu, Jun 29, 2023 at 05:39:34PM +0200, Laszlo Ersek wrote: > On 6/29/23 14:54, Richard W.M. Jones wrote: > > On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote: > >> Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we > >> suppress the exception (we log it in verbose mode only, even). > >> > >> That's not proved helpful: it almost certainly leads to later errors, but > >> those errors are less clear than the original (suppressed) excep...

On 6/29/23 17:48, Richard W.M. Jones wrote: > On Thu, Jun 29, 2023 at 05:39:34PM +0200, Laszlo Ersek wrote: >> On 6/29/23 14:54, Richard W.M. Jones wrote: >>> On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote: >>>> Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we >>>> suppress the exception (we log it in verbose mode only, even). >>>> >>>> That's not proved helpful: it almost certainly leads to later errors, but >>>> those errors are less clear than the original (suppr...

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024 v1 was here: <https://listman.redhat.com/archives/libguestfs/2023-June/031910.html>. Make any "chown_for_libvirt_rhbz_1045069" failure a hard one; that way the user gets to see more direct and more uniform error messages (namely that we couldn't connect to libvirt). Document those connection problems, and a simple way to start up all libvirt daemons. Laszlo Ersek (3): lib/utils: fix typo lib/utils: make &qu...

...| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/utils.mli b/lib/utils.mli index 5687bf75867e..cf88a467fd54 100644 --- a/lib/utils.mli +++ b/lib/utils.mli @@ -62,7 +62,7 @@ val backend_is_libvirt : unit -> bool (** Return true iff the current backend is libvirt. *) val chown_for_libvirt_rhbz_1045069 : string -> unit -(** If running and root, and if the backend is libvirt, libvirt +(** If running as root, and if the backend is libvirt, libvirt will run qemu as a non-root user. This prevents access to root-owned files and directories. To fix this, provide a function to chown...