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

[macOS] Enable Process support on MacCatalyst #61504

Closed
MaximLipnin opened this issue Nov 12, 2021 · 13 comments · Fixed by #61507
Closed

[macOS] Enable Process support on MacCatalyst #61504

MaximLipnin opened this issue Nov 12, 2021 · 13 comments · Fixed by #61507
Assignees
Milestone

Comments

@MaximLipnin
Copy link
Contributor

MaximLipnin commented Nov 12, 2021

For these API's, they should work near equivalent as they do on OSX. There may be small behavior differences when App Sandbox is enabled. We should determine where the spots are and account for them.

PNSE for Process on iOS / tvOS, but enabled for MacCatalyst.

@akoeplinger @steveisok

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Nov 12, 2021
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@steveisok steveisok added the os-ios Apple iOS label Nov 12, 2021
@ghost
Copy link

ghost commented Nov 12, 2021

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

Since the private Apple APIs are not available on iOS/tvOS (e.g. see #61265 (comment)), they are going to be excluded on those platforms but still may work on MacCatalyst.
To handle such cases, we need to add code to detect App Sandbox at runtime. For example, Process.Start() would need to know whether it can work.
Also it would make sense to throw a proper PlatformNotSupportedException() when sandbox is enabled.

@akoeplinger @steveisok

Author: MaximLipnin
Assignees: -
Labels:

untriaged, os-ios

Milestone: -

@steveisok steveisok added area-Interop-mono and removed untriaged New issue has not been triaged by the area owner labels Nov 12, 2021
@steveisok steveisok added this to the 6.0.x milestone Nov 12, 2021
@mdh1418
Copy link
Member

mdh1418 commented Nov 15, 2021

Do we only want to throw PlatformNotSupportedException for private Apple APIs when App Sandbox is enabled? Does using the APIs when the sandbox isn't enabled throw errors?

Is it clear yet what all the private APIs/system resources we would want to throw PlatformNotSupportedException when Sandbox is enabled? (are these the only ones? _proc_listallpids, _proc_pid_rusage, _proc_pidinfo, _proc_pidpath)

@MaximLipnin
Copy link
Contributor Author

Do we only want to throw PlatformNotSupportedException for private Apple APIs when App Sandbox is enabled? Does using the APIs when the sandbox isn't enabled throw errors?

If I'm not mistaken, that's mostly about Mac Catalyst so if one wants to publish catalyst app to App Store then they have to enable sandbox and must not use those private API. In this case we will throw PNSE.
Otherwise, in case the sandbox is off, theoretically some apple APIs might not work (tbh, no idea which ones), then we could throw PNSE as well.

Is it clear yet what all the private APIs/system resources we would want to throw PlatformNotSupportedException when Sandbox is enabled? (are these the only ones? _proc_listallpids, _proc_pid_rusage, _proc_pidinfo, _proc_pidpath).

Perhaps, this list is not full atm. Having done app sandbox detection, we can handle all such APIs one by one.

@steveisok
Copy link
Member

If I'm not mistaken, that's mostly about Mac Catalyst so if one wants to publish catalyst app to App Store then they have to enable sandbox and must not use those private API. In this case we will throw PNSE. Otherwise, in case the sandbox is off, theoretically some apple APIs might not work (tbh, no idea which ones), then we could throw PNSE as well.

Yes, this is correct. Some customers will use MacCatalyst as a desktop application and never publish to the AppStore. It would make sense for that group to not have the sandbox enabled and use the api's that would otherwise be restricted.

@mdh1418
Copy link
Member

mdh1418 commented Nov 15, 2021

Because it sounds like Sandbox contains damage, then should there be warnings if Sandbox is disabled and some private Apple APIs and system resources are accessed to let the customers know that it might affect their system? Is that something that should be from our end?

@steveisok
Copy link
Member

Because it sounds like Sandbox contains damage, then should there be warnings if Sandbox is disabled and some private Apple APIs and system resources are accessed to let the customers know that it might affect their system? Is that something that should be from our end?

I think it may depend on how we want to surface the PNSE.

@rolfbjarne do you know if turning the sandbox on and off is a project setting?

@rolfbjarne
Copy link
Member

@rolfbjarne do you know if turning the sandbox on and off is a project setting?

It's an entitlement that's configured per project, so yes, it's effectively a project setting.

I have a few thoughts:

  • Apple may change what's allowed and not in the sandbox in the future. For instance, Apple might introduce a new entitlement that allows apps in the sandbox to launch processes.
  • Normal macOS apps can also be sandboxed, it's not restricted to Mac Catalyst (although I believe what the app can and can't do inside the sandbox differs).
  • I think the sole purpose of detecting the sandbox would be to able to give the developer useful information if something fails - it's not in any case meant to replace/substitute/replicate the sandbox itself.
  • To our knowledge, Apple does currently not scan macOS/Mac Catalyst apps for usage of private/disallowed APIs when publishing them on the App Store - the only restriction is that the app has to be sandboxed, and then at execution time, some APIs will fail in a sandboxed environment (this isn't restricted to private APIs: posix_spawn and other process-launching APIs aren't private, they're just not allowed in the sandbox).

@akoeplinger
Copy link
Member

To our knowledge, Apple does currently not scan macOS/Mac Catalyst apps for usage of private/disallowed APIs when publishing them on the App Store - the only restriction is that the app has to be sandboxed, and then at execution time, some APIs will fail in a sandboxed environment (this isn't restricted to private APIs: posix_spawn and other process-launching APIs aren't private, they're just not allowed in the sandbox).

This is good to know because it makes one worry I had less important: if we detect sandbox at runtime then the private APIs will still be in the binary unless we teach linker to strip them out via some project setting (which is doable, but more work and has edge cases e.g. if the user wants to disable linker but still publish to App Store).

@simonrozsival
Copy link
Member

posix_spawn and other process-launching APIs aren't private, they're just not allowed in the sandbox

@rolfbjarne I tested spawning processes from sandboxed apps this week and it seems to work just fine (e.g., I'm able to run ls or php). Do you have links to some resources according to which this shouldn't be possible or have you tested it yourself?

@simonrozsival
Copy link
Member

If I understand the docs correctly, you should be able to run world readable binaries (+ anything that is bundled with the app) and it will run in the context of the app's sandbox with the same limitations: access to the network might be limited, it might be able to touch only certain external files, etc.

@rolfbjarne
Copy link
Member

IIRC @akoeplinger was the one who tested this some time ago

@simonrozsival
Copy link
Member

simonrozsival commented Nov 29, 2021

TIL that to detect app sandbox at runtime you can just check if the APP_SANDBOX_CONTAINER_ID environment variable is set

@steveisok steveisok changed the title [macOS] Detect App Sandbox at runtime [macOS] Enable Process support on MacCatalyst Dec 1, 2021
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Dec 1, 2021
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Dec 7, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jan 7, 2022
steveisok pushed a commit that referenced this issue Jan 11, 2022
This PR adds support for Process.Start() and Process.Kill() for Mac Catalyst. I also added a way to run Mac Catalyst tests in App Sandbox and I resolved the problems with libproc in App Sandbox (the app is unable to obtain a list of running processes).

Closes #61295, closes #61504.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants