Yes, NSTask (I think) and Process() inherent the sandbox
toggle quoted messageShow quoted text
In a sandboxed application, child processes created with the Process class inherit the sandbox of the parent app. You should generally write helper applications as XPC Services instead, because XPC Services allows you to specify different sandbox entitlements for helper apps. See Daemons and Services Programming Guide and XPC for more information.”
I ran into this and just decided to not use sandbox nor sell the app on the App Store, just not worth the extra hassle.
On 9 Jul 2019, at 11:47 am, Graham Cox <firstname.lastname@example.org> wrote:
In my app I use NSTask to launch a copy of ffmpeg as a child process to do some work in the background on a video stream.
I pass parameters to this task via the command line arguments through NSTask. One of the arguments is where to send its ‘progress’ output, which I direct to /dev/stdout, which in turn I open as a file handle so my app receives these notifications. I parse what comes back to update my UI in various ways.
This all works fine when the app is built unsandboxed.
When it is sandboxed, the NSTask fails to launch because it doesn’t have permission to open /dev/stdout
I’m wondering how to deal with this. If I just create a URL for /dev/stdout and then call -startAccessingSecurityScopedResource on it, that has no effect, but it’s probably naive to think it would. The launched task is responsible for opening the stream, and I have no idea what exactly it does to do that anyway - it’s all internal to ffmpeg.
Can this even be done in a sandboxed app?