Linux install script: safety upgrade

[RichardHaselgrove]

Describe the bug
The new install script places the data directory at '/var/lib/boinc': previous repository installations have often used '/var/lib/boinc-client'.

I have now come across a project application - Quantum Chemistry at GPUGrid - which has the boinc-client version hard-coded in its cuda compile script. That's stupid, of course, but not under our direct control. The tasks fail with:

FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/boinc-client/.cupy', from https://www.gpugrid.net/results.php?hostid=625407&offset=0&show_names=0&state=5&appid=47

Suggestion
Many of the distro repo versions created a folder redirect entry at '/var/lib/boinc', to catch similar errors and redirect them to boinc-client. We should do the same in reverse - catching boinc-client and redirecting it to plain boinc. I have done that on the failing machine, and it is producing valid completions now.

System Information

• OS: Linux (all versions)
• BOINC Version: 8.0.4+

[AenBleidd]

But that is a valid error: no project application should ever access any other folder except 'projects' and 'slots/N'.
That is GPUGrid who violates security rules.
You should redirect this error to them, and they should fix their application to not depend on any BOINC installation directory.

[RichardHaselgrove]

I disagree. It is good programming etiquette to anticipate potential errors, and mitigate their potential effect.

Especially when making changes to established custom and practice ...

[AenBleidd]

A good etiquette is to create a software that doesn't violate security, and here GPUGrid obviously failed.
Why we should follow their path and violate security too?

[RichardHaselgrove]

So that we can contribute positively to scientific research?

[AenBleidd]

Ok to follow your logic: why we are running BOINC on Linux under special 'boinc' user with limited permissions if we can allow running it with sudo?
That's not a good way for our users.
Every project MUST create secure software and follow security guidelines.

[RichardHaselgrove]

Many private (non-commercial) volunteers do that already. They have to have sudo access, because they don't have the backup of a professional sysadmin service to do it for them.

[AenBleidd]

I am very sorry but I don't support this.
The issue you reported us not an issue on our side but it uncovered a hidden issue of GPUGrid.
Please report this to them.
This is something they need to fix in a proper way.

[AenBleidd]

Just as a reference: https://www.ncsc.gov.uk/information/secure-default#

[RichardHaselgrove]

Well, you can see what you think of https://www.gpugrid.net/forum_thread.php?id=5428&nowrap=true#61811

Closing this conversation for now - my domestic electricity supply is about to be turned off (for an upgrade - not because I haven't paid my bill!)

[sef43]

thanks for finding this @RichardHaselgrove

We use cupy in one of the GPUGRID apps. You can see here it has default values for this runtime environmental variable:
https://docs.cupy.dev/en/stable/reference/environment.html#envvar-CUPY_CACHE_DIR

This one in particular looks to be set to ${HOME}/.cupy which seems sensible to me

We use the boinc wrapper to run the python code.
Somewhere the HOME variable is getting set to /var/lib/boinc-client/ by the wrapper/client

I can change the app to set the variable to the current running dir.

[AenBleidd]

@sef43, you are correct. This folder (.cupy) should be in the slots/N directory or in case it need to be shared between your running application instances - in your projects/YOUR_PROJECT folder

[davidpanderson]

I agree.