Created attachment 2032134 [details] Full output of `LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 unshare --user virt-inspector --add disk.qcow2 --no-applications --no-icon` Description of problem: virt-inspector fails when run under a user namespace. Version-Release number of selected component (if applicable): 1.52.0 How reproducible: 100% Steps to Reproduce: 1. unshare --user virt-inspector --add disk.qcow2 --no-applications --no-icon Actual results: libguestfs: error: appliance closed the connection unexpectedly. This usually means the libguestfs appliance crashed. Do: export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 and run the command again. For further information, read: http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs You can also run 'libguestfs-test-tool' and post the *complete* output into a bug report or message to the libguestfs mailing list. libguestfs: error: guestfs_launch failed. This usually means the libguestfs appliance failed to start or crashed. Do: export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 and run the command again. For further information, read: http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs You can also run 'libguestfs-test-tool' and post the *complete* output into a bug report or message to the libguestfs mailing list. Expected results: <?xml version="1.0"?> <operatingsystems> <operatingsystem> [...] </operatingsystem> </operatingsystems> Additional info: Full output of `LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 unshare --user virt-inspector --add disk.qcow2 --no-applications --no-icon` attached.
It all goes very seriously wrong, very early: mount: /proc: must be superuser to use mount. dmesg(1) may have more information after failed mount system call. (corresponding to https://github.com/libguestfs/libguestfs/blob/master/appliance/init#L20) I don't understand how that can happen.
So we don't really have any idea, but our best guess is the initramfs isn't happy. Can you recreating it? rm -rf /var/tmp/.guestfs-*/ before running 'libguestfs-test-tool'. Also, this is standard Fedora 40?
`sudo rm -rf /var/tmp/.guestfs-* && LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 unshare --user libguestfs-test-tool` leads to the same result. This is standard Fedora 40.
I did: sudo rm -rf /var/tmp/.guestfs-* unshare --user libguestfs-test-tool # fails libguestfs-test-tool # successful and diffed the output between runs. There's no obvious difference in appliance creation steps. But the appliances are a bit different. In the unshare case: $ guestfish --ro -a /var/tmp/.guestfs-65534/appliance.d/root -i Welcome to guestfish, the guest filesystem shell for editing virtual machine filesystems and disk images. Type: ‘help’ for help on commands ‘man’ to read the manual ‘quit’ to quit the shell Operating system: Fedora Linux 40 (Server Edition Prerelease) /dev/sda mounted on / ><fs> ll / total 96 drwxr-xr-x 19 root root 4096 May 8 10:22 . drwxr-xr-x 20 root root 4096 May 8 10:24 .. dr-xr-xr-x 2 nobody nobody 4096 Jan 24 00:00 afs lrwxrwxrwx 1 root root 7 May 8 10:22 bin -> usr/bin dr-xr-xr-x 2 nobody nobody 4096 Apr 14 12:51 boot drwxr-xr-x 2 nobody nobody 4096 May 4 11:34 dev drwxr-xr-x 58 nobody nobody 4096 Mar 25 11:45 etc drwxr-xr-x 2 nobody nobody 4096 Jan 24 00:00 home -rwxr-xr-x 1 nobody nobody 7646 Nov 16 10:48 init lrwxrwxrwx 1 root root 7 May 8 10:22 lib -> usr/lib lrwxrwxrwx 1 root root 9 May 8 10:22 lib64 -> usr/lib64 drwx------ 2 root root 16384 May 8 10:22 lost+found drwxr-xr-x 2 nobody nobody 4096 Jan 24 00:00 media drwxr-xr-x 2 nobody nobody 4096 Jan 24 00:00 mnt drwxr-xr-x 2 nobody nobody 4096 Jan 24 00:00 opt dr-xr-xr-x 2 nobody nobody 4096 Apr 4 20:07 proc dr-xr-x--- 2 nobody nobody 4096 May 2 16:59 root drwxr-xr-x 10 nobody nobody 4096 May 7 17:36 run lrwxrwxrwx 1 root root 8 May 8 10:22 sbin -> usr/sbin drwxr-xr-x 2 nobody nobody 4096 Jan 24 00:00 srv dr-xr-xr-x 2 nobody nobody 4096 Apr 4 20:07 sys drwxrwxrwt 2 nobody nobody 4096 May 8 10:22 tmp drwxr-xr-x 12 nobody nobody 4096 Mar 25 11:45 usr drwxr-xr-x 18 nobody nobody 4096 Apr 4 20:07 var ><fs> ll /bin/mount -rwsr-xr-x 1 nobody nobody 49088 Feb 16 00:00 /sysroot/usr/bin/mount In the normal case: $ guestfish --ro -a /var/tmp/.guestfs-1000/appliance.d/root -i Welcome to guestfish, the guest filesystem shell for editing virtual machine filesystems and disk images. Type: ‘help’ for help on commands ‘man’ to read the manual ‘quit’ to quit the shell Operating system: Fedora Linux 40 (Server Edition Prerelease) /dev/sda mounted on / ><fs> ll / total 96 drwxr-xr-x 19 root root 4096 May 8 10:19 . drwxr-xr-x 20 root root 4096 May 8 10:24 .. dr-xr-xr-x 2 root root 4096 Jan 24 00:00 afs lrwxrwxrwx 1 root root 7 May 8 10:19 bin -> usr/bin dr-xr-xr-x 2 root root 4096 Apr 14 12:51 boot drwxr-xr-x 2 root root 4096 May 4 11:34 dev drwxr-xr-x 58 1000 1000 4096 Mar 25 11:45 etc drwxr-xr-x 2 root root 4096 Jan 24 00:00 home -rwxr-xr-x 1 1000 1000 7646 Nov 16 10:48 init lrwxrwxrwx 1 root root 7 May 8 10:19 lib -> usr/lib lrwxrwxrwx 1 root root 9 May 8 10:19 lib64 -> usr/lib64 drwx------ 2 root root 16384 May 8 10:19 lost+found drwxr-xr-x 2 root root 4096 Jan 24 00:00 media drwxr-xr-x 2 root root 4096 Jan 24 00:00 mnt drwxr-xr-x 2 root root 4096 Jan 24 00:00 opt dr-xr-xr-x 2 root root 4096 Apr 4 20:07 proc dr-xr-x--- 2 root root 4096 May 2 16:59 root drwxr-xr-x 10 root root 4096 May 7 17:36 run lrwxrwxrwx 1 root root 8 May 8 10:19 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Jan 24 00:00 srv dr-xr-xr-x 2 root root 4096 Apr 4 20:07 sys drwxrwxrwt 2 root root 4096 May 8 10:19 tmp drwxr-xr-x 12 1000 1000 4096 Mar 25 11:45 usr drwxr-xr-x 18 root root 4096 Apr 4 20:07 var ><fs> ll /bin/mount -rwsr-xr-x 1 root root 49088 Feb 16 00:00 /sysroot/usr/bin/mount I think what's happened is that /bin/mount is setuid to nobody.nobody in the first case, which means that it is unable to mount filesystems such as /proc. Moving the bug to supermin. The workaround for this is to build the appliance as a separate step outside "unshare" (but as user 65534, or moving the appliance to /var/tmp/.guestfs-65534/).
Looking at https://github.com/libguestfs/supermin/blob/b6c8945aee56725b85d9a04dc41b9a661d78acb9/src/ext2fs-c.c#L778, it seems the host file's uid/gid is used? This wouldn't be correct due to the user mapping, e.g., a file owned by root on the host would appear to supermin as being owned by nobody IIUC.
We try to reproduce the host packages as faithfully as possible. One argument is that if you mess up your host filesystem, then you get to keep the pieces. Another is that since everything runs as root in the libguestfs appliance, maybe we should always use root.root for files there. (The problem here is that the binaries are created nobody.nobody, which normally doesn't matter, but it's a problem for setuid binaries like mount.) This is probably always safe. Is there a way to get the true host file's UID/GID, even when running in a user namespace? ie. to "see through" the user namespace? Is it possible to find out that you're running in a user namespace? (We could ignore UID/GID only in this case.)
(In reply to Richard W.M. Jones from comment #6) > Is it possible to find out that you're running in a user namespace? (We > could > ignore UID/GID only in this case.) On this one: $ cat /proc/self/uid_map 0 0 4294967295 If it *doesn't* contain this, then we're in a user namespace which is not the initial one. (I tried unshare --user cat /proc/self/uid_map and the file exists but is completely empty.)
That seems to be the best way to check if we're running under a user namespace. We could also parse any mappings in it and apply them in reverse to all files, but that might not be worth the trouble and there is no guarantee that there is a mapping at all for any given uid/gid.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.
Reopening because Virtualization Tools has not been discontinued.