Will my bodgie job to allow multiple local users to access the same VMs end up causing problems?

[route-bee]

Hey everybody! This is my first post so please be kind to me. I changed the ownership and permissions of the files and directories of my VirtualBox machines in order that the same VMs can be used by multiple users on my local machine. For this example I will reference my Windows 11 VM which I have called "bumbleBee" and as you can see in the following snippet from the terminal I have changed the ownership of the VM's directory to user "root" and group "vboxusers" and set the permissions of the directory to 1775 (with the sticky bit)...

Code: Select all

drwxrwxr-t 3 root vboxusers 4096 Feb 28 09:58 bumbleBee

In normal operations it seems that VirtualBox reads the file "bumbleBee.vbox" inside the bumbleBee directory before moving it to "bumbleBee.vbox-prev" and then writing a new version of bumbleBee.vbox when the VM shuts down, and if you change the ownership and permissions of the files from...

Code: Select all

-rw-rw-r-- 1 root          vboxusers          547328 Feb 27 21:52 bumbleBee.nvram
-rw------- 1 administrator administrator        6315 Feb 27 21:52 bumbleBee.vbox
-rw------- 1 administrator administrator        7354 Feb 27 21:51 bumbleBee.vbox-prev
-rw-rw-r-- 1 root          vboxusers     11953766400 Feb 27 21:52 bumbleBee.vdi
drwxrwxr-x 2 root          vboxusers            4096 Feb 27 21:52 Logs

To...

Code: Select all

-rw-rw-r-- 1 root          vboxusers          547328 Feb 28 12:36 bumbleBee.nvram
-rw-rw-r-- 1 root          vboxusers            6315 Feb 27 21:52 bumbleBee.vbox
-rw-rw-r-- 1 root          vboxusers            7354 Feb 27 21:51 bumbleBee.vbox-prev
-rw-rw-r-- 1 root          vboxusers     11953766400 Feb 28 12:36 bumbleBee.vdi
drwxrwxr-x 2 root          vboxusers            4096 Feb 28 12:36 Logs

And then run the VM as a member of the vboxusers group (administrator in this example) without setting the sticky bit in the parent directory it rewrites the vbox files with the old permissions which results in VirtualBox throwing "permission denied" error if you try to load the VM with a different user. With the sticky bit set however, the files inside the bumbleBee directory can only be moved or deleted by their owners, and if you change the ownership of the files to the user root and the group vboxusers again, and reset the permissions to 664, anyone in the vboxusers group can read and write to the files but only root can move or delete them. The result is that you don't get the "permission denied" message when VirtualBox tries to read bumbleBee.vbox as an alternate user but it doesn't update the files when it shuts down either.

The first user that I ran the updated VM under was administrator and it produced a new file called "bumbleBee.vbox-tmp" as you can see here...

Code: Select all

-rw-rw-r-- 1 root          vboxusers          547328 Feb 28 12:38 bumbleBee.nvram
-rw-rw-r-- 1 root          vboxusers            6314 Feb 28 12:14 bumbleBee.vbox
-rw-rw-r-- 1 root          vboxusers            6315 Feb 27 21:52 bumbleBee.vbox-prev
-rw------- 1 administrator administrator        7324 Feb 28 12:38 bumbleBee.vbox-tmp
-rw-rw-r-- 1 root          vboxusers     11953766400 Feb 28 12:38 bumbleBee.vdi
drwxrwxr-x 2 root          vboxusers            4096 Feb 28 12:38 Logs

The machine now works for all users in the group vboxusers but none of those users make any alterations to the files bumbleBee.vbox or bumbleBee.vbox-prev when they run the VM and only the user administrator alters the file bumbleBee.vbox-tmp when I use him to run the VM. I need to know if this hack is going to come back to bite me at some stage. Will rendering VirtualBox effectively incapable of changing the various vbox files end up causing problems? Is there a better way of allowing multiple local users to share the same VMs?

[arQon]

If you consider the basic issues of multiple users having concurrent access to *any* file on a system, you can probably work out the answer yourself.

(spoiler: Very much "yes"!)

[scottgus1]

in order that the same VMs can be used by multiple users on my local machine

I agree with arQon that there could be problems, but depending on what the above means, for there's at least two interpretations:

1. multiple users can log in at the same time (under different desktop sessions? different remote-in clients?) or can access the VMs over the network from shared folders at the same time. (Windows Terminal Services could do this, so I'm certain Linux has a method to do it too.)

2. multiple users have accounts on the PC, but only one user can log in at any time, and the VMs aren't in network shared folders, so only one person can use the VM list at one time.

1 is a problem. If two or more users try to start the same VM at once, then two or more OS's will fight over the same VM disk. The commonly-used OS's are not designed to do that and data loss will result.

2 can work fine. Only one person can run the VMs at any time, so no conflicts. That person can log off and another person log on then run VMs with no problems.

The way Windows can achieve #2 is by putting the VMs in a folder that is public for all users (like C:\Users\Public) or by setting up a folder with full read/write access permissions for the desired users. If you achieved either of these setups with your permissions, and you don't intend to allow concurrent logons, then you should be OK.

[arQon]

Yeah - essentially, if we're talking about what's effectively just different *identities*, on the same physical machine with a standard desktop-ish setup, it'll probably all work out.
But if that was the goal I'm not sure why someone would do things this way in the first place, so it seems reasonable to expect that it isn't.

[route-bee]

I'm doing it mainly to save space on my HDD and the time it would take me to duplicating the software and system configurations over my three accounts on the local host. I have a login for study, a log in for work, and a personal/administrator login all of which I have set up with different desktop applications, and different Office365 and Google accounts and whatnot.

I want to share a single account on both a shared Kali VM and a shared Fedora VM, and I want set up three users on a shared Windows 11 VM so that I can use different Windows users when logging into that VM for different purposes. The VMs will not be shared over a network, but I might switch users and start the same VM multiple times if I ever get drunk enough; that's a fault, but it's not my main concern.

My main worry is that I am loosing information that would otherwise be updated to the various bumbleBee.vbox files every time I run the VM. In normal operations (with an owner user) the file bumbleBee.vbox is moved to bumbleBee.vbox-prev and an new bumbleBee.vox file is written every time you run the VM. With the permission set as the are now however, neither file is modified, no matter how often you run the VM.

I'm going to have a play with KVM this weekend and try to figure out if it offers a way to share VMs between local users that doesn't involve breaking the application but in the mean time...

What does the vbox file do and what problems will rendering it effectively read only cause in the long term?

[scottgus1]

I have a login for study, a log in for work, and a personal/administrator login

Good, so it appears you're using option 2 above. If the VMs are in a public folder that all three login accounts can read/write into, then you can register the VMs in each account's Virtualbox (Machine menu, Add command).

I want to share a single account on both a shared Kali VM and a shared Fedora VM, and I want set up three users on a shared Windows 11 VM

The login accounts set up inside the VM OS's are handled by the VM OS's, not by Virtualbox. Those VM OS login accounts will be available regardless of which host login account runs the VM.

Virtualbox does not involve itself in the host or VM OS login accounts.

In normal operations (with an owner user) the file bumbleBee.vbox is moved to bumbleBee.vbox-prev and an new bumbleBee.vox file is written every time you run the VM.

This is correct operation, yes. However, this:

With the permission set as the are now however, neither file is modified, no matter how often you run the VM.

is a problem. The .vbox file stores the VM's 'hardware' settings. It's essentially the VM's "motherboard". Every time you change the VM's hardware, unplug a network cable, make or delete a snapshot, start the VM, etc, Virtualbox needs to overwrite the .vbox files. The permissions settings changes have broken that ability.

Note what preferences changes and Host-Only or NAT Network settings you've made in Virtualbox. You'll have to remake them.
Reboot the host so no Virtualbox processes are running.
Make a new VM storage folder in a public place on your Linux host that all of your login accounts have automatic full access to right away without any permissions adjustments.
Move the VMs to that new public folder manually. Make sure the VM files inherit permissions from the parent folder and do not have the old permissions set above still attached.
Go to each account's $HOME/.config/VirtualBox folder and rename the "Virtualbox.xml" file to "Virtualboxold.xmlold". This will completely reset Virtualbox, leaving an empty VM list and reset Preferences and network settings.
On each host login account, register each VM using the Machine menu Add command to load each VM's .vbox file. Reset the preferences and network settings.

[route-bee]

Thanks for the reply but I'm not sure how to...

Make sure the VM files inherit permissions from the parent folder and do not have the old permissions set above still attached.

I searched on Google and was unable to answer the question of how to set permission inheritance on a Linux directory.

[scottgus1]

Neither do I, unfortunately. Try your distro's support forum.

On the other hand, simply moving the files to a public folder might do it.

[arQon]

Inheritance shouldn't be relevant unless VBox is rewriting the permissions each time. However, if it's deleting the files and recreating them that counts as rewriting/resetting the permissions, so it might be.

Assuming that all your identities are members of vboxusers, which obv they should be, chmod -R +070 on the VM root folder should do it.