Re: Environment woes executing scripts from my OS X app
Re: Environment woes executing scripts from my OS X app
- Subject: Re: Environment woes executing scripts from my OS X app
- From: Rick Mann <email@hidden>
- Date: Wed, 16 Dec 2015 15:44:41 -0800
> On Dec 16, 2015, at 15:29 , Chris Hanson <email@hidden> wrote:
>
> On Dec 16, 2015, at 2:29 PM, Rick Mann <email@hidden> wrote:
>
>> - The code that calls the external scripts has to be cross-platform, and run on linux as well as OS X. So, no NSTask.
>
> Sure you can, you just have to hide the use of NSTask or posix_spawn/fork+execve behind an interface.
>
>> I'm thinking the best thing to do is pass in paths and an environment string to be used in the system() call (e.g., invoke it as "export PYTHONPATH=...; export PYTHONHOME=...; path/to/script args"). Maybe I can even leverage that to let me put the requisite python modules in the app bundle...
>
> Please don't use system(), it's extremely dangerous as it uses a command-line interpreter, and is thus subject to the vagaries of argument quoting. (Basically it's a security exploit waiting to happen.)
>
> You're far better off constructing any pipelines yourself with pipe(), and using posix_spawn() or fork() followed (immediately on OS X) by execve() to invoke your tools because you can be guaranteed all of the arguments and environment you specify will be passed with full fidelity.
>
> If you don't have posix_spawn on all your target platforms, and the app is large, it can also be useful to create your own small trampoline executable which takes the arguments and environment and working directory and so on from the parent process via standard I/O or some other mechanism, and then does the rest of the fork/exec calls itself to run the subprocesses the parent requests. The main reason is that forking a process clones it, so forking a big process to exec a small one can be expensive and you want to amortize that cost.
Agreed, but I'm trying to minimize the changes made to this code (it's owned by different engineers here). We control the deployment of this code, so the security concerns are mitigated (assuming the boxes aren't breached, but then we have other problems).
Longer-term, the solution is to embed the Python interpreter and not call out to scripts. Longer-long-term, the solution is to switch from the Python (NumPy) code to C++, and not use Python at all, but there's very little impetus to do this.
--
Rick Mann
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden