Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BOINC refuses to add exclusive application it can't execute, like Windows UWP apps #2826

Closed
GreenReaper opened this issue Nov 15, 2018 · 2 comments

Comments

@GreenReaper
Copy link

GreenReaper commented Nov 15, 2018

On Windows 10, UWP apps such as the Xbox app (which may be impacted, particularly by GPU execution) cannot be added as exclusive applications because BOINC does not recognize them as executable:

'XboxApp.exe' is not an executable application.

This is even though the apps can be executed, and indeed may be running, as that user or another.

Here is a screenshot of the advanced security settings for this executable.
(I wasn't able to upload it to the issue - "Something went really wrong".)

As you can see it provides a condition to executablilty:

WIN://SYSAPPID Contains "MICOSOFT.XBOXAPP_..."

This is an AppContainer package moniker attached to the impersonation security token upon app execution.

The issue is that BOINC is checking for the ability to open for executability by the BOINC process:

if (!fn.IsOk() || !fn.IsFileExecutable()) {

In practice this file can be opened as executable, even by the user, but only when actually executing the app. Indeed it seems that this problem is already known (to an extent) based on a line just a little further down:

// wxFileName::IsFileExecutable() doesn't seem to work on Windows,


I therefore suggest that executability not be tested - after all, you might want to disable BOINC when applications are running which the user in question cannot execute, even as an app, if it interferes with them.

At the end of the day, BOINC needs a list of filenames to processes it can see running. If if it gets a validly-formatted filename (not necessarily an existing file), as fn.IsOk() implies, should that not be enough?


I'm not sure it should even test (e.g. fn.FileExists()) whether the file can be accessed by the current user, since that is not a requirement for it being a running process on the computer - though I don't know if you can still see the filename in the process list in that case.

In this light a file picker might not be the ideal option, but it'd be possible to remove wxFD_FILE_MUST_EXIST which would allow users to enter filenames that aren't visible to them:

wxFD_OPEN|wxFD_FILE_MUST_EXIST|wxFD_MULTIPLE|wxFD_CHANGE_DIR

This would also save time when the user knows the filename they want to enter, but not its location.

@Ferroin
Copy link

Ferroin commented Nov 15, 2018

I'm inclined to agree, the requirement that exclusive apps be executable by the BOINC process seems entirely bogus to me, especially because it's reasonably certain to not be the case for certain types of application when running BOINC as a service.

davidpanderson added a commit that referenced this issue Nov 23, 2018
…ability.

... because the file may be inaccessible to or not executable by user.
Also don't require .exe or .app extension.

The user can use the file picker to locate the file, but they don't have to;
they can just type in the file name.

Addresses issue #2826
@AenBleidd AenBleidd added this to Backlog in Client and Manager via automation Mar 13, 2019
@AenBleidd AenBleidd added this to the Client Release 7.16 milestone Mar 13, 2019
@AenBleidd
Copy link
Member

Fixed via #2843

Client and Manager automation moved this from Backlog to Done Mar 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

No branches or pull requests

3 participants