> On Dec 16, 2015, at 15:29 , Chris Hanson <c...@mac.com> wrote: > > On Dec 16, 2015, at 2:29 PM, Rick Mann <rm...@latencyzero.com> 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 rm...@latencyzero.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
