Bug 1222186 - VirtualBox not allowed to access USB devices although user is in vboxusers group
Summary: VirtualBox not allowed to access USB devices although user is in vboxusers group
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Virtualization:Other (show other bugs)
Version: Current
Hardware: Other openSUSE Tumbleweed
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Larry Rainey
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-31 09:49 UTC by T Adams
Modified: 2024-04-06 01:03 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
fix path: 'etc' --> 'dev' (see newer diff!) (464 bytes, patch)
2024-04-01 03:26 UTC, robert spitzenpfeil
Details | Diff
fix directory permissions and buggy stderr redirection (688 bytes, patch)
2024-04-01 03:26 UTC, robert spitzenpfeil
Details | Diff
fix device node / folder perms (457 bytes, patch)
2024-04-01 14:09 UTC, robert spitzenpfeil
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description T Adams 2024-03-31 09:49:27 UTC
Since DUPing this morning to the big 20240329 Tumbleweed snapshot (re CVE-2024-3094), I have again lost USB passthrough to scanners in my Win 7 VM in Virtualbox 7.14.  

In the ~/.config/VirtualBox/VBoxSVC.log, I see many instances of:

-----------

00:00:11.669981 nspr-5   WARNING [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={e54f6256-97a7-4947-8a78-10c013ddf4b8} aComponent={HostWrap} aText={VirtualBox is not currently allowed to access USB devices.  You can change this by adding your user to the 'vboxusers' group.  Please see the user manual for a more detailed explanation}, preserve=true aResultDetail=0

-----------

However, the user already was in the vboxusers group!

I also see that while logged in as user, I can't see the contents of /dev/vboxusb.  The directory is shown as locked, and belonging to vboxusers.

Troubleshooting steps taken so far:

* Remove user from vboxusers, reboot, add user back to vboxusers, reboot.  It didn't help.

* Uninstall the VirtualBox extension pack, reboot, re-install the extension pack, reboot.  This also didn't help.

I'm not 100% certain that this problem appeared only with the 20240329 snapshot.    I haven't used the scanners in a few days, might have DUPd to an earlier snapshot in the meantime.
Comment 1 Larry Rainey 2024-03-31 14:50:02 UTC
Known issue with 6.8 kernel - Oracle is also aware.
USB query returns no devices which is why none show up.

Issue is also in 15.6 and Slowroll.

Other Flavors of Linux like Mint Linux and 6.8 also have this issue.
Comment 2 Claudio Marcial Peon 2024-03-31 14:51:06 UTC
I tried today to install Virtual Box, and I experienced the same problem but I was on 2024031. 

I DUP to 20240329 and the issue remains.
Comment 3 robert spitzenpfeil 2024-04-01 03:02:07 UTC
Observations:

* permissions for /dev/vboxusb are wrong
* I was missing /dev/udev/rules.d/60-vboxdrv.rules (created by vboxdrv.sh)


* /usr/lib/virtualbox/vboxdrv.sh

lines 63-65 should (IMO) read (it was /etc/vboxusb on my box):

chmod "${DEVICE_MODE}" /dev/vboxusb/
chmod "${DEVICE_MODE}" /dev/vboxusb/*
chmod "${DEVICE_MODE}" /dev/vboxusb/*/*


* /usr/lib/virtualbox/VBoxCreateUSBNode.sh

line 56 should read (there should be no space after 2):

chmod 0660 "$devpath" 2> /dev/null

I've added a line after that to fix directory perms

find /dev/vboxusb -type d -exec chmod g+x {} \;


* What's still not OK:

after reboot, the perms for /dev/vboxusb are wrong, only after plugging in say a usb stick udev triggers running the script and perms are ok. If you want to pass through a built-in usb device, this is not good.
Comment 4 robert spitzenpfeil 2024-04-01 03:06:52 UTC
Don't mind the last bullet point. Now it works for me.
Comment 5 robert spitzenpfeil 2024-04-01 03:10:10 UTC
I've had to run vboxdrv.sh setup (as root) to re-create the missing udev rules.
Comment 6 robert spitzenpfeil 2024-04-01 03:26:00 UTC
Created attachment 873962 [details]
fix path: 'etc' --> 'dev'
(see newer diff!)
Comment 7 robert spitzenpfeil 2024-04-01 03:26:57 UTC
Created attachment 873963 [details]
fix directory permissions and buggy stderr redirection
Comment 8 Claudio Marcial Peon 2024-04-01 11:06:53 UTC
Thanks Robert. I can confirm that making those changes you suggest on https://bugzilla.suse.com/show_bug.cgi?id=1222186#c3 everything works again.
Comment 9 T Adams 2024-04-01 12:30:59 UTC
I'm afraid that these steps didn't help for me.  I made the changes indicated in:

https://bugzilla.suse.com/attachment.cgi?id=873962&action=diff

and in:

https://bugzilla.suse.com/attachment.cgi?id=873963&action=diff

with the change from 660 to 650 in lines 50 and 52, and also ran /usr/lib/virtualbox/vboxdrv.sh restart 

On reboot, I still get a locked /dev/vboxusb directory, and the user enumeration error on firing up the Windows VM.  

I'm on snapshot 20240329.
Comment 10 Javier de San Pedro 2024-04-01 12:36:10 UTC
Suffering the same problem, but as far as I can see to me it is because of these changes to the package: https://build.opensuse.org/request/show/1163382#comments  , rather than any kernel changes. 

I left a message there, but not sure since anyone is notified about it. I don't know what the intention of the patch is but in addition to the /etc/vboxusb type (which I didn't see either :) ) , setting 0660 to /dev/vboxusb looks wrong to me. 

As I say on the message there, my recommendation is to just avoid doing these chmod workarounds in the virtualbox packaging. I don't know if this was introduced due to bug 1219766 or something else, but to me it doesn't sound like something that should be workarounded silently in the virtualbox package. 

Just reverting these vboxusb chmod workarounds from the package (as in https://build.opensuse.org/package/rdiff/home:javispedro:fixpkgs/virtualbox?linkrev=base&rev=5 ) for me makes USB passthrough work again in TW.
Comment 11 Claudio Marcial Peon 2024-04-01 12:46:25 UTC
(In reply to T Adams from comment #9)
> I'm afraid that these steps didn't help for me.  I made the changes
> indicated in:
> 
> https://bugzilla.suse.com/attachment.cgi?id=873962&action=diff
> 
> and in:
> 
> https://bugzilla.suse.com/attachment.cgi?id=873963&action=diff
> 
> with the change from 660 to 650 in lines 50 and 52, and also ran
> /usr/lib/virtualbox/vboxdrv.sh restart 
> 
> On reboot, I still get a locked /dev/vboxusb directory, and the user
> enumeration error on firing up the Windows VM.  
> 
> I'm on snapshot 20240329.

After a reboot, I have to run again

/usr/lib/virtualbox/vboxdrv.sh restart

After that the enumeration error is gone, at least until the next reboot
Comment 12 Larry Rainey 2024-04-01 13:36:17 UTC
The issue is wrong major minor numbers

the should be
crw-rw---- 1 root vboxusers 10, 122 Apr  1 08:24 /dev/vboxdrv
crw-rw-rw- 1 root root      10, 121 Apr  1 08:24 /dev/vboxdrvu
crw-rw---- 1 root vboxusers 10, 120 Apr  1 08:24 /dev/vboxnetctl

they are

crw-rw---- 1 root vboxusers 10, 120 Apr  1 07:27 /dev/vboxdrv
crw-rw---- 1 root vboxusers 10, 119 Apr  1 07:27 /dev/vboxdrvu
crw-rw---- 1 root vboxusers 10, 118 Apr  1 07:27 /dev/vboxnetctl

I have a good fix - need others to validate it.

sudo /usr/lib/virtualbox/vboxdrv.sh start will fix it without a reboot with this file

too big to paste here so here is a link put it in /usr/lib/virtualbox/

https://paste.opensuse.org/pastes/9641ebe078e6
Comment 13 robert spitzenpfeil 2024-04-01 14:08:43 UTC
See my comment #3

--- I now think this is wrong, as it also set the perms for the directories to 0660

* /usr/lib/virtualbox/vboxdrv.sh

lines 63-65 should (IMO) read (it was /etc/vboxusb on my box):

chmod "${DEVICE_MODE}" /dev/vboxusb/
chmod "${DEVICE_MODE}" /dev/vboxusb/*
chmod "${DEVICE_MODE}" /dev/vboxusb/*/*


---

If I replace all the chmod lines with:

find /dev/vboxusb -type f -exec chmod "${DEVICE_MODE}" {} \;
find /dev/vboxusb -type d -exec chmod g+x {} \;


The perms for the device nodes are 0600 (OK)
The perms for the (previously created) folders just get g+x (just in case) and are _not_ overwritten with 0660 (no g+x)
Comment 14 robert spitzenpfeil 2024-04-01 14:09:17 UTC
Created attachment 873974 [details]
fix device node / folder perms
Comment 15 Javier de San Pedro 2024-04-01 14:11:54 UTC
(In reply to Larry Rainey from comment #12)
> The issue is wrong major minor numbers

Sorry, I don't understand, can you elaborate how to reproduce that problem with wrong minor for vboxdrv? Sounds like a udev issue. It would also entirely prevent vbox from working, not just USB passthrough. 

I am now very confused, as I see the package installs a /usr/lib/udev/rules.d/60-vboxdrv.rules , _but at the same time_ running vboxdrv.sh setup will create /etc/udev/rules.d/60-vboxdrv.rules 

I never had to run "vboxdrv.sh setup", it has always worked without that (since we had kmp package in TW). In fact I didn't have the /etc/udev/rules.d/60-vboxdrv.rules at all in my system. 

> I have a good fix - need others to validate it.
> 
> sudo /usr/lib/virtualbox/vboxdrv.sh start will fix it without a reboot with
> this file
> 
> too big to paste here so here is a link put it in /usr/lib/virtualbox/
> 
> https://paste.opensuse.org/pastes/9641ebe078e6

In any case, the attached vboxdrv.sh does not fix the issue. Just running "start" will chmod /dev/vboxusb back to 0660 and as I mentioned above for me this is wrong.
Comment 16 robert spitzenpfeil 2024-04-01 14:13:40 UTC
Correction to comment #13:

The perms for the device nodes are 0660 (OK)
The perms for the (previously created) folders just get g+x (just in case) and are _not_ overwritten with 0660 (no g+x)
Comment 17 T Adams 2024-04-01 14:17:55 UTC
>After a reboot, I have to run again
> /usr/lib/virtualbox/vboxdrv.sh restart

Thanks, Claudio.  I did try this, but without effect on the enumeration error.

I fear I'm not competent enough to do extensive editing of these configuration files, will wait until you more knowledgeable openSUSErs find a fix.
Comment 18 Larry Rainey 2024-04-01 14:29:09 UTC
You have to replace the one in /usr/lib/virtualbox/vboxdrv.sh with the one in susepaste just running will not fix the issue - you have to vi new.sh with the code in susepaste then chmod 755 new.sh, then sudo new.sh. If it fixes your usb issue then move new.sh to /usr/lib/virtualbox/vboxdrv.sh

I matched exactly how Oracle Virtualbox installed the device nodes.

That is how they do it - so I matched it. It did fix the USB issue.

Could robert spitzenpfeil do a diff on mine vs the one zypper installed? and tell me what program you used - I had one in Windows XP but not in Linux that did the side by side.
Comment 19 robert spitzenpfeil 2024-04-01 14:34:43 UTC
I just use "diff -u", but if you want a decent diff-gui "kompare" or "kdiff" are not bad (KDE of course).
Comment 20 Javier de San Pedro 2024-04-01 14:46:05 UTC
(In reply to Larry Rainey from comment #18)
> You have to replace the one in /usr/lib/virtualbox/vboxdrv.sh with the one
> in susepaste just running will not fix the issue - you have to vi new.sh
> with the code in susepaste then chmod 755 new.sh, then sudo new.sh. If it
> fixes your usb issue then move new.sh to /usr/lib/virtualbox/vboxdrv.sh
> 
> I matched exactly how Oracle Virtualbox installed the device nodes.

Regarding the /vbox/vboxdrvu permissions and owner, I agree: this is how Oracle installs things. However, I wouldn't do this change anyway because it just opens up some attack surface to users outside the vboxusr group. I also don't see why this would fix any vboxusb issue. 

The problem with vboxusb is because of these snippets:

diff -u /usr/lib/virtualbox/vboxdrv.sh pastebin_vboxdrv.sh 
@@ -60,6 +60,10 @@
 
 [ -r /etc/default/virtualbox ] && . /etc/default/virtualbox
 
+chmod "${DEVICE_MODE}" /dev/vboxusb/
+chmod "${DEVICE_MODE}" /dev/vboxusb/*
+chmod "${DEVICE_MODE}" /dev/vboxusb/*/*
+
 begin_msg()
 {
     test -n "${2}" && echo "${SCRIPTNAME}: ${1}."

This should be entirely removed. chmod /dev/vboxusb to 0660 just makes accessing this directory impossible for vboxuser users and _should not be needed at all_ since the VBoxCreateUsbNode.sh script works fine (and also require no patches).  

If this was for bug 1219766, we should never silently workaround it in the script, and rather fix it in systemd level (which to my knowledge has already been fixed). 


Also, regarding this other change:

@@ -249,6 +254,20 @@
     if grep -q usb_device /proc/devices; then
         mkdir -p -m 0750 /dev/vboxusb 2>/dev/null
         chown root:vboxusers /dev/vboxusb 2>/dev/null
+
+       rm /dev/vboxnetctl
+       mknod -m 0660 /dev/vboxnetctl c 10 120
+       # mknod -m 0660 /dev/vboxnetctl with major 10 and minor 120
+       chown root:vboxusers /dev/vboxnetctl
+       rm /dev/vboxdrvu
+       mknod -m 0666 /dev/vboxdrvu c 10 121
+       # mknod -m 0666 /dev/vboxdrvu with major 10 and minor 121
+        chown root:root /dev/vboxdrvu 2>/dev/null
+       rm /dev/vboxdrv
+       mknod -m 0660 /dev/vboxdrv c 10 122
+       # mknod -m 0660 /dev/vboxdrv with major 10 and minor 122
+        chown root:vboxusers /dev/vboxdrv 2>/dev/null
+
     fi
     succ_msg "VirtualBox services started"
 }


This is dangerous. (misc) minors can be assigned dynamically and may be different between different sessions. But I just can't see how this can be possibly related to USB, unless we are merging multiple issues here.


Can't we do just something like https://build.opensuse.org/package/rdiff/home:javispedro:branches:Virtualization/virtualbox?linkrev=base&rev=2 to remove these vboxusb workarounds? For me at least it fixes the issue. 

I would be submitting a request, but I can't get OBS to cooperate today (it fails to publish my packages due to requiring a SSL certificate, the first time I see this).
Comment 21 Bauglir 2024-04-03 01:13:02 UTC
(In reply to robert spitzenpfeil from comment #14)
> Created attachment 873974 [details]
> fix device node / folder perms

This fix, without any other modification to vboxdrv.sh or VBoxCreateUSBNode.sh, worked for me. Thank you so much Robert.
Comment 22 T Adams 2024-04-03 06:22:12 UTC
(In reply to Bauglir from comment #21)
> (In reply to robert spitzenpfeil from comment #14)
> > Created attachment 873974 [details]
> > fix device node / folder perms
> 
> This fix, without any other modification to vboxdrv.sh or
> VBoxCreateUSBNode.sh, worked for me. Thank you so much Robert.

Thanks also for your efforts, Robert.  But for me, alas:

https://bugzilla.suse.com/attachment.cgi?id=873974&action=diff

* again made visible the contents of /dev/vboxusb, but with the directory still shown as locked

* eliminated the 'not currently allowed to access USB devices' in ~/.config/VirtualBox/VBoxSVC.log

but:

didn't restore USB passthrough to the scanners in the Win VM.
Comment 23 robert spitzenpfeil 2024-04-03 08:00:14 UTC
The problem is 2-fold.

The changes in vboxdrv.sh should leave you with correct folder permissions after boot.

The changes to VBoxCreateUSBNode.sh take care of device node permissions.


IMO you need both.
Comment 24 T Adams 2024-04-03 08:13:51 UTC
(In reply to robert spitzenpfeil from comment #23)
> The problem is 2-fold.
> 
> The changes in vboxdrv.sh should leave you with correct folder permissions
> after boot.
> 
> The changes to VBoxCreateUSBNode.sh take care of device node permissions.
> 
> 
> IMO you need both.

So, I should make the changes in:

https://bugzilla.suse.com/attachment.cgi?id=873974&action=diff  
for vboxdrv.sh 

and also the changes in:

https://bugzilla.suse.com/attachment.cgi?id=873963&action=diff

for VBoxCreateUSBNode.sh.  (Including the permission changes in lines 50 and 52)  Is that correct?  If so, I'll give it a try.
Comment 25 T Adams 2024-04-03 10:19:01 UTC
(In reply to T Adams from comment #24)
> (In reply to robert spitzenpfeil from comment #23)
> > The problem is 2-fold.
> > 
> > The changes in vboxdrv.sh should leave you with correct folder permissions
> > after boot.
> > 
> > The changes to VBoxCreateUSBNode.sh take care of device node permissions.
> > 
> > 
> > IMO you need both.
> 
> So, I should make the changes in:
> 
> https://bugzilla.suse.com/attachment.cgi?id=873974&action=diff  
> for vboxdrv.sh 
> 
> and also the changes in:
> 
> https://bugzilla.suse.com/attachment.cgi?id=873963&action=diff
> 
> for VBoxCreateUSBNode.sh.  (Including the permission changes in lines 50 and
> 52)  Is that correct?  If so, I'll give it a try.

Thank you, Robert!  I made the changes in comment 24, and also re-started vboxdrv.sh before rebooting.  The /dev/vboxusb directories are still shown as locked, but both scanners now work properly in the Windows 7 VM.
Comment 26 Javier de San Pedro 2024-04-03 10:39:57 UTC
(In reply to Javier de San Pedro from comment #20)
> I would be submitting a request, but I can't get OBS to cooperate today (it
> fails to publish my packages due to requiring a SSL certificate, the first
> time I see this).

I managed to submit this request at the end. The fix should be in Tumbleweed in a couple of days.
Comment 27 T Adams 2024-04-04 08:08:05 UTC
I believe that Javier's fix arrived in the 20240402 snapshot.  Both of my scanners work under VB in the Windows 7 VM.

If no one objects, I will mark this bug as resolved tomorrow, 4/5.

Thanks very much to everyone to helped troubleshoot this issue!
Comment 28 Thomas Rother 2024-04-04 13:24:03 UTC
confirmed, Javier's fix seems to be deployed on VERSION_ID="20240402"
and apparently it is successful. The vbox.log of a win 10 machine shows that the usb devices are detected and from inside the VM, they are also available (here tested with a Reiner SCT secure card reader):

thommie@localhost:~/local> less win10-2024-04-04-15-20-01.log | grep usb
00:00:01.050548 [/Devices/usb-xhci/] (level 2)
00:00:01.050549 [/Devices/usb-xhci/0/] (level 3)
00:00:01.050552 [/Devices/usb-xhci/0/Config/] (level 4)
00:00:01.050553 [/Devices/usb-xhci/0/LUN#0/] (level 4)
00:00:01.050554 [/Devices/usb-xhci/0/LUN#0/Config/] (level 5)
00:00:01.050555 [/Devices/usb-xhci/0/LUN#1/] (level 4)
00:00:01.050556 [/Devices/usb-xhci/0/LUN#1/Config/] (level 5)
00:00:01.050557 [/Devices/usb-xhci/0/LUN#999/] (level 4)
00:00:01.050558 [/Devices/usb-xhci/0/LUN#999/Config/] (level 5)
Comment 29 Claudio Marcial Peon 2024-04-04 21:40:19 UTC
Confirmed. Updating to 20240402 fix the issue permanently.
Comment 30 T Adams 2024-04-05 06:18:07 UTC
Fixed!