[vbox-dev] malinline vboxsf vs bundled vboxsf mount options differences (was Removing suid root bit from VBoxDRMClient)
Hans de Goede
hdegoede at redhat.com
Tue Jun 9 11:08:46 GMT 2020
Hi Frank,
On 6/8/20 7:44 PM, Frank Batschulat wrote:
> Thanks Hans, but right now we have a higher priority problem with fedora 32,
> that is we cannot get our vboxsf kernel module loaded anymore when we install
> our GAs because the Linux vboxsf kernel module is sticking and the only one getting loaded
> even though the Fedora specific guest additions you mentioned below have been uninstalled.
>
> Also the Linux kernel vboxsf kernel module is incompatible with
> our userland commands, our userland cannot talk to your vboxsf kernel module anymore.
>
> investigating and fixing these beauty currently has a higher priority for us.
I'm sorry that this is causing problems for you. When we discussed merging
a version of vboxsf modified to match the upstream kernel coding conventions
into the mainline kernel this was discussed and back then we (1) agreed that
the VirtualBox bundled version of vboxsf would also move to using the new option
string based mount parameters, which would allow you to completely drop
mount.vboxsf from the Linux guest-additions. I still think that that is the
best way forward.
Note that the mainline kernel version checks for mount.vboxsf using the
old binary options struct:
if (options && options[0] == VBSF_MOUNT_SIGNATURE_BYTE_0 &&
options[1] == VBSF_MOUNT_SIGNATURE_BYTE_1 &&
options[2] == VBSF_MOUNT_SIGNATURE_BYTE_2 &&
options[3] == VBSF_MOUNT_SIGNATURE_BYTE_3) {
vbg_err("vboxsf: Old binary mount data not supported, remove obsolete mount.vboxsf and/or update your VBoxService.\n");
return -EINVAL;
}
(the error text is based on the agreement we had that the bundled vboxsf
would move to the new mount format too).
So you could first try the old binary options struct and if you then get
-EINVAL, try again with an options string, or you could do it the other
way around. You need to change this in both mount.vboxsf and the
VBoxService code for automatically mounting shared folders marked for auto-marking.
In the Fedora packages we simply do not package mount.vboxsf and we have
a patch for the latter here:
https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/0001-VBoxServiceAutoMount-Change-Linux-mount-code-to-use-.patch
Note this patch blindly moves to using the new string based format,
but it should help as a start with making the utils support both
formats.
If you decide to go with trying the old binary mount options first then
I can modify the error message to make it less "scary", but ideally
the bundled vboxsf version would also move to using string based mount
options. As said that will also allow dropping your own special mount.vboxsf
binary.
1) Me and various VirtualBox devs, I need to dig into my mail archive if
you want more details.
Regards,
Hans
p.s.
Somewhat related, since the Fedora kernel now ships with all necessary kernel
modules for fully support all guest-addition features; and since Fedora
also has the guest-additions packages and we are doing a good job of keeping
those up2date with the latest upstream releases. I'm wondering why bother
with having upstream provided guest-additions for newer Fedora versions at
all? Would it not be better to have the huest-additions installer detects
this is a new enough Fedora and have it tell the user that the OS already
comes with the latest guest-additions (and maybe run a
"dnf update virtualbox-guest-additions") ?
For any guest-additions on Fedora bug-reports, which are not reproducable
on say the latest Ubuntu, you could then also simply point people to
bugzilla.redhat.com and then we can pick it up.
I think that only having one version would lower both our support
workloads ?
I would also welcome you directly contributing to the Fedora pkgs.
We use a gitforge based workflow, where you can clone the repo
containing our packaging bits:
https://src.fedoraproject.org/rpms/virtualbox-guest-additions
And then submit a pull-req with any changes. I would be happy to accept
pull-requests from you for this. And once you've shown that you
know the workflow and packaging rules I would be happy to give you
direct commit rights.
>
> On Mon, 08 Jun 2020 17:46:58 +0200, Hans de Goede <hdegoede at redhat.com> wrote:
>
>> Hi All,
>>
>> While looking into upgrading the Fedora virtualbox-guest-additions packages to 6.0.10
>> I noticed that the "VBoxClient --vmsvga-x11" call in VBoxClient-all has been replaced
>> with "VBoxClient --vmsvga" and that that one will either behave as the old --vmsvga-x11
>> version (when running under a X11 session) or it will start /usr/bin/VBoxDRMClient.
>>
>> I added /usr/bin/VBoxDRMClient to the Fedora packages, but after that resizing of
>> a GNOME3 as Wayland-compositor session inside the guest still did not work.
>>
>> The issue seems to be that /usr/bin/VBoxDRMClient needs more rights, I guess that
>> the upstream version of the guest-additions installs it suid root ?
>>
>> That is not necessary and since Fedora ships virtualbox-guest-additions as part of
>> the default workstation install we would like to avoid adding another suid root binary
>> to the default install.
>>
>> Instead I've written a udev rule + systemd service to replace the "VBoxClient --vmsvga"
>> call inside VBoxClient-all. These config files will start /usr/bin/VBoxDRMClient
>> when running inside a VBox VM with VMSVGA graphics. Note this will now run independent
>> of the type of session (X11 or Wayland) running inside the VM. This means that X11
>> sessions now also use VBoxDRMClient rather then VBoxClient --vmsvga-x11 for resizing.
>>
>> This works fine and if upstream adopts this, then the VBoxClient --vmsvga-x11
>> can be dropped.
>>
>> The udev rule and systemd file can be found here. Feel free to use these under the
>> MIT license:
>>
>> https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/VirtualBox-60-vboxguest.rules
>> https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/vboxclient.service
>>
>> Regards,
>>
>> Hans
>>
>> _______________________________________________
>> vbox-dev mailing list
>> vbox-dev at virtualbox.org
>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
>
More information about the vbox-dev
mailing list