SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am completely new to VirtualBox and have built VirtualBox 2.0.6 from a SlackBuild script on a clean Slackware 12.1 install. I built and installed acpica, dev86, virtualbox-ose (with addons ISO) and virtualbox-kernel.
No compile errors.
I created the vboxusers group and added my user to it and logged out/in - group shows in output of groups command.
I made rc.vboxdrv and rc.vboxnet executable and started them both.
When I attemtpt to start the GUI as normal user with /usr/bin/VirtualBox3 I get:
Callee RC: NS_ERROR_FACTORY_NOT_REGISTERED
And it fails to run.
If I do the same as root user it starts OK.
I have re-re-read the VB documentation and Slackbuild notes but feel I must be missing something simple - path or permission maybe?
Check the permissions of /dev/vboxdrv. Chances are that it's root/root. A suggested way is to have the group id be vboxusers, and add vboxusers to the group list of anyone you want to give access to VirtualBox.
Added:
Sorry, it's late. I see that you've added vboxusers, but did you set the group id for /dev/vboxdrv to that?
Last edited by Quakeboy02; 12-01-2008 at 01:42 AM.
...did not return any significant info on google, and I initially dismissed the error that appeared in the startup terminal window as a side-effect of the the other...
Wrong owner (0) of '/tmp/.vbox-slacker-ipc'.
...mostly because...
ls -al /tmp
...did not show any such file or directory, and ...and all other permissions including /drv/vboxdrv appeared to be correct according to the docs.
But it was operator error I suppose because after coming back to it after a break I found...
So, you enabled hardening by default.
But the SlackBuild of vbox-ose from SBo should have set suid.
try: chmod 4511 <path-to-`VirtualBox'-in-vbox-lib-dir>
So, you enabled hardening by default.
But the SlackBuild of vbox-ose from SBo should have set suid.
try: chmod 4511 <path-to-`VirtualBox'-in-vbox-lib-dir>
Yes I enabled hardening by default. As I said, I am completely new to VirtualBox and it is my understanding that hardening basically means that access permissions to the vboxdrv is restricted - seemed like a good idea to me. It looks to me like the SBo script only passes the --enable-hardening parameter to the VirtualBox configure script but does not make any changes of it's own, unless the udev rules do it... is that correct?
I have not found any explanation of why my 'executable' is VirtualBox3 instead of VirtualBox - is that related to hardening also? Oh well, I am learning...
Yes I enabled hardening by default. As I said, I am completely new to VirtualBox and it is my understanding that hardening basically means that access permissions to the vboxdrv is restricted - seemed like a good idea to me. It looks to me like the SBo script only passes the --enable-hardening parameter to the VirtualBox configure script but does not make any changes of it's own, unless the udev rules do it... is that correct?
Hardening means that access to VirtualBox, in all ways, is restricted to users of the vboxusers group. Not only the kernel module, but also all (frontend) apps. Therefore the script does not only pass "--enable-hardening" to configure, but also forces the use of the vboxusers group and installs the affected binaries suid root (affected apps check for UID 0 on startup). With hardening disabled but vboxusers enabled, binaries are not installed suid root and can be run by any user in the vboxusers group.
Honestly, although I understand the vboxusers-configuration (and think it's a good idea), I still don't get what the benefit in security should be by forcing the VirtualBox binaries to run as root. But upstream requested it as default, so....
Quote:
I have not found any explanation of why my 'executable' is VirtualBox3 instead of VirtualBox - is that related to hardening also? Oh well, I am learning...
It's called "VirtualBox3" because it's using the Qt3 GUI. If you have enabled the Qt4 GUI as well/instead you'll have a "VirtualBox" binary (which is the upstream default by now). Qt3 GUI is the default in the SlackBuild for two reasons. First, Slackware 12.1 does not ship Qt4, so users would need to install it as well to run the GUI. Not necessary if the user doesn't want to and an alternative is available. Second, as the Qt4 GUI was presented as default with VirtualBox 2.0.0 is was way more unstable than the Qt3 GUI, so there wasn't much sense in setting it as default. However, in the meantime both GUIs are equally stable and one should preferably use the Qt4 GUI by now as the Qt3 one might be removed from upstream anytime.
But I still can't run it as a normal user, nor I can cd /usr/lib/virtualbox. The root suid is there, and the "world" flags don't allow read or execute.
Actually you don't need to explicitly define VBOXUSERS, as it's set to "yes" by default.
Quote:
But I still can't run it as a normal user, nor I can cd /usr/lib/virtualbox. The root suid is there, and the "world" flags don't allow read or execute.
That doesn't make sense, as the relevant code in the script is *only* executed when hardening is enabled. I suspect the generated package being right as you want, but maybe something on install is not working as expected. Anyway, it's rather late here, I'll have a look at it tomorrow.
When I try to run a VM that I previously created with Vbox 1.6.x I get this message:
Quote:
VirtualBox kernel driver is not accessible, permission problem. If you have built VirtualBox yourself, make sure that you do not have the vboxdrv kernel module from a different build or installation loaded. Also, make sure the vboxdrv udev rule gives you the permission you need to access the device..
VBox status code: -1909 (VERR_VM_DRIVER_NOT_ACCESSIBLE).
I think this appeared after I tried to change the permitions of /dev/vboxdrv but it keeps popping after re-installing and re-starting.
Alright, after taking a closer look at the script again, and also on your two posts I think you missunderstood some things. I try to explain the options again in detail:
Code:
HARDENING=yes VBOXUSERS=yes
- UPSTREAM / SLACKBUILD DEFAULT
- binaries installed suid root: yes
- user must be part of group vboxusers: yes
- VirtualBox runnable for users not in vboxusers: no
Code:
HARDENING=no VBOXUSERS=yes
- binaries installed suid root: no
- user must be part of group vboxusers: yes
- VirtualBox runnable for users not in vboxusers: no
Code:
HARDENING=no VBOXUSERS=no
- binaries installed suid root: no
- user must be part of group vboxusers: no
- VirtualBox runnable for users not in vboxusers: yes
As you now probably know, you seem to have configured virtualbox in another way then what you expected it to be. Your errors are all caused by the fact, that your user is not part of the vboxusers group. As you told the script to use the vboxusers group by passing "VBOXUSERS=yes" to the script, that would be the expected behavior and there is nothing wrong.
And I can run it as a normal user but when I try to launch a VM I get this error:
Code:
VirtualBox kernel driver is not accessible, permission problem. If you have built VirtualBox yourself, make sure that you do not have the vboxdrv kernel module from a different build or installation loaded. Also, make sure the vboxdrv udev rule gives you the permission you need to access the device..
VBox status code: -1909 (VERR_VM_DRIVER_NOT_ACCESSIBLE).
Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
Console
Interface:
IConsole {e3c6d4a1-a935-47ca-b16d-f9e9c496e53e}
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.