Avvio dell'eseguibile con NSTask - Problemi di sandboxing?

Question

Ho un'applicazione Mac OSX che avvia un eseguibile situato in/Contents/Resources. L'applicazione non è destinata ad essere rilasciata su App Store e quindi non ho sandbox attivato.

Il codice di lancio:

toolPath = [[[NSBundle mainBundle] pathForResource:@"myexecutable" ofType:@""] copy]; 
task = [[NSTask alloc] init]; 
[task setLaunchPath: toolPath]; 
pipe = [[NSPipe alloc] init]; 
[task setArguments:[NSArray arrayWithObjects:@"-someArg", someVariable, nil]]; 
file = [[NSFileHandle alloc] initWithFileDescriptor:[pipe fileHandleForReading].fileDescriptor]; 
[task setStandardOutput: stderrPipe]; 
[task launch]; 

Il fatto è - questo tutto funziona bene durante l'esecuzione in Xcode. Funziona bene anche quando si esporta l'applicazione sul desktop e si esegue.

Tuttavia, se eseguo il zip dell'applicazione, caricarlo su un server Web e quindi scaricarlo sullo stesso computer (o trasferirlo su un altro Mac), l'attività non viene più avviata! Non ricevo errori nella console di sistema o altro.

Ho ricercato alcuni su questo problema e ho scoperto che OSX segnerà una nuova applicazione come permesso speciale "in quarantena". Così ho studiato la differenza tra l'applicazione scaricata e l'applicazione esportata:

autorizzazioni per l'eseguibile dopo l'esportazione mia applicazione da Xcode:

-rwxr-xr-x 1 Username staff 65724 21 Jul 16:31 executableName 

A questo punto l'applicazione funziona benissimo e l'eseguibile viene lanciato da un pulsante all'interno dell'app.

E dopo zippare l'applicazione, caricato al server, scaricato, Cerniera aperta, e aprire l'applicazione e accettando la "Questa applicazione è stata scaricata da internet" dialogo:

-rwxr-xr-x 1 Username staff 65724 21 Jul 16:31 executableName 
    com.apple.quarantine  26 

A questo punto non succede nulla quando spingo il pulsante nella mia app.

Se dunque io corro xattr -rd com.apple.quarantine su tutto l'app, l'avviso di quarantena viene rimosso:

-rwxr-xr-x 1 Username staff 65724 21 Jul 16:31 executableName 

ma l'eseguibile è ancora non in fase di lancio!

A questo punto ora ho le seguenti autorizzazioni sul mio desktop app:

/Contents/MacOS:

-rwxr-xr-x 1 Username staff 407728 21 Jul 16:31 appName 

/Contents/Resources:

-rwxr-xr-x 1 Username staff 65724 21 Jul 16:31 executableName 

E sulla scaricato app che ho usato xattr -rd su:

/Contents/MacOS:

-rwxr-xr-x 1 Username staff 407728 21 Jul 16:31 appName 

/Contents/Resources:

-rwxr-xr-x 1 Username staff 65724 21 Jul 16:31 executableName 

La prima applicazione funziona bene e la seconda non lancia l'eseguibile. Che diavolo sta succedendo? È la stessa app, sullo stesso computer, con le stesse autorizzazioni, ma quella scaricata non funziona.

Questo problema viene visualizzato su tutte le versioni OSX su computer diversi.

Answer 1

Aggiunta del com.apple.security.inherit diritto al app helper risolto questo problema per me.

La mia app di supporto si è bloccata con Could not set sandbox profile data: Operation not permitted (1) quando ho provato ad avviarlo con NSTask.

dalla documentazione di Apple:

Se la vostra applicazione si avvale di un processo figlio creato sia con la funzione posix_spawn o la classe NSTask, è possibile configurare il processo figlio di ereditare la sandbox del suo genitore. Tuttavia, l'utilizzo di un processo figlio non fornisce la sicurezza garantita dall'utilizzo di un servizio XPC.

Per abilitare sandbox eredità, un target bambino deve utilizzare esattamente due App Sandbox chiavi entitlement: com.apple.security.app-sandbox e com.apple.security.inherit. Se si specifica qualsiasi altra autorizzazione Sandbox App, il sistema interrompe il processo figlio. Tuttavia, è possibile conferire altre funzionalità a un processo figlio tramite iCloud e le autorizzazioni di notifica.

L'app principale in un progetto Xcode non deve mai avere un valore SÌ per il diritto ereditario.

Spero che questa soluzione sia d'aiuto.

Answer 2

Alla fine ho scoperto che cosa ha causato questo problema, è successo quando si tenta di avviare un eseguibile con NSTask che scrive file. Stranamente, questo funziona bene in alcuni casi, come menzionato nel post originale. Ma per farlo funzionare su altri computer ho finito con l'utilizzo di STPrivilegedTask che ha risolto il problema.