Hi Richard and Lersek,
Thanks for your help on this issue and thanks for picking up my patch
and applying it upstream!
On Tue. 20 June 2023 à 17:10, Richard W.M. Jones <rjo...@redhat.com> wrote:
> I think you've solved the problem now, but for future reference you
> can run:
>
> $ virt-rescue
Perfect! This last comment was what I needed for my final investigation.
The UUID 65534 problem showed up again. Within the qemu VM, the active
user is indeed root.
However,
$ ls -al /bin/mount
-rwsr-xr-x 1 65534 65534 55528 May 30 15:42 /bin/mount
Where 65534 corresponds to the user "nobody" and the group "nogroup".
So the root cause was that the bazel sandbox created an environment in
which SUID programs had a different UID and GID than expected. The
guestfs-tools would just copy those IDs when creating the qemu rootfs.
Even if /bin/mount was executed as root, the SUID makes it run
effectively as nobody. This is kind of comical: it is the first time
that I see a SUID resulting in a drop of privilege ¯\_(ツ)_/¯.
At this point, I just gave up on using the bazel sandbox for the
particular target in which I need guestfs-tools.
For the record, and in case anyone has the same issue as I did and
find this thread, the sandbox can be disabled for a particular target
by using the "no-sandbox" tag. Example:
genrule(
name = "rootfs",
srcs = ["rootfs.tar"],
outs = ["rootfs.ext4"],
tags = ["no-sandbox"],
cmd = "virt-make-fs --format=raw --type=ext4 --size=+500M $< $@",
)
Yours sincerely,
Vincent Mailhol
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
