Comme vous le savez peut-être, Google Chrome fonctionne en tant que une application multiprocessus . Le processus initial "Google Chrome" gère l'interface utilisateur et héberge un certain nombre d'autres processus. Un nouveau processus "renderer" est créé pour chaque onglet que vous ouvrez dans Chrome, un processus "plugin" pour chaque extension que vous installez, et un processus "GPU" distinct pour le code qui communique avec le GPU du système. Chacun de ces autres processus apparaît dans le moniteur d'activité en tant que processus "Google Chrome Helper".
Pour rendre Chrome plus sûr, les processus de rendu s'exécutent dans un environnement de type bac à sable . Ils ne peuvent communiquer avec le réseau que par l'intermédiaire du processus hôte et ne peuvent communiquer qu'avec des fichiers spécifiques (par exemple, les polices et les profils ColorSync). Ils ne peuvent pas non plus communiquer avec d'autres processus du système, ce qui est à l'origine de ces messages. Les processus de rendu essaient de communiquer avec les processus launchserviced et windowservice, mais en sont empêchés à cause de leur bac à sable.
Ce bogue a été résolu par un ingénieur logiciel de l'équipe de sécurité Chrome de Google avec un s'engager en février 2014. La suppression de cette ligne de code a permis de résoudre le problème.
[NSApplication sharedApplication];
Entre autres choses, l'appel à la méthode sharedApplication ouvre une connexion entre une application et le WindowServer d'OS X, que vous pouvez voir échouer dans l'erreur CGSLookupServerRootPort.
L'intention était que Chrome appelle cette méthode pour "s'échauffer" certaines ressources avant l'activation du bac à sable ; l'accès à certains fichiers, processus ou ressources réseau avant la mise en place des restrictions du bac à sable. Cependant, il semble qu'à un moment donné, cette tentative ait commencé à échouer, ce qui a entraîné l'apparition de ces erreurs dans le journal. Je pense qu'Apple a considéré ce "réchauffement" comme une tentative de contournement du bac à sable et a commencé à le réprimer.
Si je lis correctement, ce changement a atteint le canal de sortie stable avec un mise à jour de Google Chrome vers 34.0.1847.131 en avril 2014.
Il est intéressant de noter que l'équipe Chrome avait discuté de supprimer ces appels à la méthode sharedApplication en octobre 2013 et a même discuté supprimer entièrement Cocoa des processus de rendu comme objectif en 2009.
Dans le même ordre d'idées, Apple a publié un correctif de sécurité en avril 2014 pour résoudre un bogue où "des sessions WindowServer pouvaient être créées par des applications en bac à sable".
