boinc
boinc copied to clipboard
Modify Windows installer to enable secure BOINC to run VirtualBox tasks
Some testing has been done in connection with a vboxwrapper modification. It points out that
- the secure installation of BOINC on Windows correctly adds the user account
boinc_master. boinc_masterowns a Windows user profile and can create%USERPROFILE%\.VirtualBoxto write it's VirtualBox profile there.
Nonetheless, boinc_master doesn't have enough access rights to run simple commands like VBoxManage -q list systemproperties.
More details here: https://github.com/BOINC/boinc/pull/6116#issuecomment-2697297479 https://github.com/BOINC/boinc/pull/6116#issuecomment-2697383766
It should be investigated which installer modifications are required to allow boinc_master to run VirtualBox tasks.
The installer should then be modified accordingly.
@computezrmle, is there a possibility that you could test this? I might have a solution for this issue, but I'm not sure I'm able to reproduce this.
@AenBleidd I don't run BOINC on Windows but Crystal-Pellet is a reliable Windows tester for LHC@home.
@Crystal-Pellet Could you please test it?
I did a try. After installation no BOINC service was created. I did the test with 8.0.2 installed as a service and replaced the 8.0.2 boinc.exe by the 8.1.0 version of 3/19/2025 00:26 (6.046.720 bytes) I started the service and a directory below users was created with the name boinc_master.LT1 (LT1 = PCname) That directory stays empty. During startup these lines in eventlog: 9 20 Mar 07:12:35 The BOINC client version has changed from 8.0.2 to 8.1.0. 10 20 Mar 07:12:35 WSL: registry open failed 11 20 Mar 07:12:35 [error] get_wsl_information(): Error -1
I tried a LHC Theory VBox-task and that ended into the known access error after a few seconds. Output of stderr.txt: <core_client_version>8.1.0</core_client_version>
Onjuiste functie. (0x1) - exit code 1 (0x1)
It seems to me that secure mode should mean that apps run as a separate user, NOT that the client runs as a separate user.
It seems to me that secure mode should mean that apps run as a separate user, NOT that the client runs as a separate user.
Yes, that is how it works on the Mac. The purpose is to protect against project applications that might cause damage or steal personal information either maliciously or unintentionally. Thee is little concern about the client doing those things.
Yeah. Vitalii, am I right in assuming that Win secure mode has the client run as a separate user? That would account for the registry access failing. Can we change that?
Or we could remove secure mode on Win. I doubt that many people use it.
It seems to me that secure mode should mean that apps run as a separate user, NOT that the client runs as a separate user.
Running BOINC in secure mode (as a service), boinc.exe is running under the account of boinc_master and so the apps started by BOINC.
Or we could remove secure mode on Win. I doubt that many people use it.
That would be the easiest way, since also GPU-tasks don't run when secure mode is used.
Yeah. Vitalii, am I right in assuming that Win secure mode has the client run as a separate user?
Correct.
Can we change that?
Need to be investigated.
Or we could remove secure mode on Win. I doubt that many people use it.
I doubt as well. Also, I think that either running VBox when running BOINC as a service was never working or was broken for quite a long time. When BOINC runs as a service, there is no way to run application that uses GPU. So at the moment, running CPU only applications is possible.
I suggest deprecating this feature in the next release, and remove it afterwards.
@Crystal-Pellet,
After installation no BOINC service was created.
This was a bug, now it's fixed.
Ok, some additional information.
WSL by default is installed separately for every particular user, so obviously if BOINC client runs under a separate account, there is no WSL installed for that user.
What is more important, since this is a limited user, there is no access to the HKEY_CURRENT_USER registry hive as well.
So at the moment we have the next situation:
| Feature | Normal installation | Service installation |
|---|---|---|
| CPU | ✔️ | ✔️ |
| GPU | ✔️ | ❌ |
| VBox | ✔️ | ❌ |
| WSL | ✔️ | ❌ |
I can try to fix that for VBox (not sure I succeed here: I have a couple of ideas to check, but the first one I doubt will work, the second one will lower the security level), but I don't think it's reasonable to invest a lot of time here:
- Looks like VBox doesn't work for service installation for several years already, and since we have never got any reports about it, nobody uses it.
- We want to deprecate VBox functionality in future.
That is why I suggest doing the next:
- In the current installer extend the text for the service installation saying that not only GPU but also VBox and WSL will not work.
- Put also a warning that this mode is deprecated.
- Wait for a couple of releases for feedback, and remove this functionality completely together with VBox support (will take a couple of years for that until all the projects that use VBox now switch to WSL/Docker).
@davidpanderson, what do you think?
Sounds good!