Bug 2279710
| Summary: | supermin creates appliances with files owned by nobody.nobody when called with 'unshare --user' | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Alberto Faria <afaria> | ||||
| Component: | supermin | Assignee: | Richard W.M. Jones <rjones> | ||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | unspecified | CC: | mhicks, ptoscano, rjones | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2025-10-17 00:11:17 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Alberto Faria
2024-05-08 08:20:21 UTC
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. |