The contents of the gui rpc password file can be randomly generated by script during the installation, and this then does not pose a security concern about packaging a password in a pkg.Ī general principle of a software package is that it should not leave the package installed in an unusable state after installation.This ensures that the exes running under the boinc account can't access user's personal files. On modern distributions, users personal files are in their group with the same name as the user, or the "users" group, which the boinc account should NOT be part of.We are not protecting boinc from the user, we are protecting the user and the machine from boinc. Let's not get confused here on what we are trying to protect. Permissions around the current user having access to BOINC resources (such as being a member of the boinc group) points in the opposite direction to the real security concern, which should be ok. The man in the middle attack would be very difficult, because BOINC uses TLS certificate validation in the communication process. BOINC by its very nature is an "untrusted" component, so the biggest security issue is BOINC executables attacking the rest of the machine, via the injection of a bad project exe via a man in the middle attack or a bad project, not the other way around.It does need 660 perms, and the current user should be part of the boinc group. The gui rpc password file does not need world (666 or 777 perms) to solve the problem.Started Google Earth.I agree with Vitalii and I think the issues around security here are largely misguided. Then set NON-BOINC CPU load to 4%, reran the test. Turned on SMT on my CPU, allowed 23 Rosetta tasks to start and run for a while. This is on Windows 10 with a single CPU (Ryzen 3900X running single threaded) 11:55:10 | | Suspending computation - CPU is busy 11:55:10 | | suspend work if non-BOINC CPU load exceeds 7% 11:55:10 | | Reading preferences override file I just tested it on my system with setting the value to 7%, then ran a Kaspersky database update (which uses 8% CPU). It happens irrespective of which projects attached to (seems to be a clear BOINC scheduling problem) Even if fully loaded, BOINC continues to compute.Įven suspending and resuming manually while the task is running resumes the BOINC computation tasks when CPU usage is already over 95%. This machine is used for multithreaded compilation which bumps CPU usage outside of BOINC to 95%+ when active, and BOINC should suspend, but it doesn't. Hardware: 2x 6c/12t Xeon L5640 (24 logical processors total) Set "suspend when non-boinc cpu usage is above": 30% (also tried 50%)īOINC should suspend computation when the heavy load task runs.Use 50% of processors on a high core count machine.BOINC isn't suspending computation when non-BOINC cpu usage is high, despite having settings to suspend computation to that effect.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |