Impossibile accedere all'elemento portachiavi dopo l'aggiornamento SMJobBless

Question

Abbiamo un problema con l'aggiornamento di uno strumento di supporto con SMJobBless che ci ha lasciato perplessi per giorni.

stiamo sviluppando un'applicazione per cui ad un certo punto abbiamo bisogno di eseguire attività amministrative (carico/scarico di un kext). Stiamo anche utilizzando il portachiavi per archiviare le informazioni dell'account per la nostra applicazione.

Per le attività amministrative, utilizziamo uno strumento di supporto che viene installato utilizzando SMJobBless con cui comunichiamo tramite porte DO su Mach (con NSConnection).

Nello strumento di aiuto:

// use our bundle id as our service name 
NSString* name = [[NSBundle mainBundle] bundleIdentifier]; 

launch_data_t checkinRequest = launch_data_new_string(LAUNCH_KEY_CHECKIN); 
launch_data_t checkinResponse = launch_msg(checkinRequest); 
launch_data_t machServicesDict = launch_data_dict_lookup(checkinResponse, LAUNCH_JOBKEY_MACHSERVICES); 
launch_data_t machPort = launch_data_dict_lookup(machServicesDict, [name UTF8String]); 

mach_port_t mp = launch_data_get_machport(machPort); 

launch_data_free(checkinResponse); 
launch_data_free(checkinRequest); 

NSMachPort *receivePort = [[NSMachPort alloc] initWithMachPort:mp]; 
NSConnection *server = [NSConnection connectionWithReceivePort:receivePort sendPort:nil];   

Nell'applicazione:

NSConnection *conn = [NSConnection connectionWithRegisteredName:HELPER_BUNDLE_IDENTIFIER host:nil]; 

id proxyServerObject = [conn rootProxy]; 

if(conn && proxyServerObject) { 
    return [proxyServerObject someMethod]; 
} 
return NO; 

Firmiamo sia l'applicazione e lo strumento di supporto utilizzando un certificato codesign da Thawte. Finora, tutto funziona come un fascino. Lo strumento di supporto è installato e possiamo comunicare con esso utilizzando DO; il nostro kext viene caricato e scaricato con successo.

Il problema inizia quando si tenta di aggiornare il nostro strumento di supporto. Utilizziamo il dizionario delle informazioni dello strumento installato e lo strumento in bundle nel nostro pacchetto di app per verificare se è necessario un aggiornamento dello strumento e chiamare nuovamente SMJobBless per eseguire l'aggiornamento.

Dopo la chiamata SMJobBless, le seguenti righe vengono visualizzati nella console:

6/19/12 10:31:24.000 AM kernel: CODE SIGNING: cs_invalid_page(0x104e17000): p=74362[OURAPP] clearing CS_VALID 
6/19/12 10:31:24.000 AM kernel: CODE SIGNING: cs_invalid_page(0x10d0de000): p=74364[OURAPPHELPER] clearing CS_VALID 

Dopo questo, l'applicazione è in grado di leggere la password applicazione dal nostro articolo portachiavi, la funzione SecKeychainItemCopyContent rendimenti errSecAuthFailed (-25293). Tuttavia, non viene segnalato alcun errore se si verifica manualmente la firma del codice del nostro strumento helper o pacchetto applicativo installato utilizzando codesign -vvvv PATH_TO_TOOL_OR_BUNDLE. Lo strumento e l'applicazione sono firmati all'esterno dell'ambiente Xcode e il contenuto non viene modificato dopo la procedura di firma.

Abbiamo trovato one other post che descrive una situazione simile, ma questa domanda è ancora senza risposta. Un problema correlato potrebbe essere SMJobBless returning error 4098.

Stiamo testando su OSX 10.7.4.

Chiunque ha affrontato problemi simili o c'è qualcosa di ovvio che stiamo sbagliando?

Answer 1

Ciò è dovuto ad un bug relativo a come SMJobBless sostituisce lo strumento di supporto su disco. In particolare, modifica il binario in posizione anziché adottare l'approccio comune di scrivere su un file temporaneo e quindi rinominarlo sopra la destinazione. L'effetto di ciò è che se il file binario è in memoria, le modifiche al file cambiano le pagine di memoria che supportano il file, invalidando la loro firma del codice. Ho scritto un bug report su questo come rdar: // problema/13514523. Ti incoraggerei a presentare la tua se non l'hai già fatto.

Una possibile soluzione potrebbe essere quella di chiedere all'applicativo di rimuovere dal disco l'applicazione prima di utilizzare SMJobBless per aggiornarlo. Ciò dovrebbe comportare la copia SMJobBless in un nuovo file sul disco, ignorando il problema.