10.12 Sierra impossible de désactiver GateKeeper

Ours Gris

Membre enregistré
12 Février 2017
4
2
87
Un logiciel de comptabilité pro refuse de s'ouvrir avec Sierra 10.12.3, et il n'y a aucun équivalent dans le monde Mac. J'ai essayé de désactiver GateKeeper avec la commande du Terminal " spctl --master-disable", et même essayé "spctl --status --master-disable", j'obtiens toujours la même réponse : permission denied. J'étais bien dans mon compte d'administrateur d'administrateur.
Si je n'ai pas fait d'erreur, quelqu'un connaît-il la nouvelle commande à utiliser ?
 
Pourquoi aller utiliser le terminal ?
Clic droit sur le logiciel, lancer le logiciel, cliquer là où il faut pour passer outre l'alerte qui s'affiche, et c'est plié.
Le logiciel devrait se lancer sans autre formalité les fois suivantes.
S'il ne lance pas, c'est qu'il y a un problème ailleurs (il est corrompu, par exemple).

https://www.macg.co/os-x/2016/10/ma...eeper-pour-lancer-un-logiciel-non-signe-95905
 
Dernière édition:
Sierra empêche de s'ouvrir beaucoup de logiciels qui ne sont pas signé, ou que leur code est modifié par des tiers.
le terminal demande le mot de passe administrateur (après Enter), sinon ça ne marchera pas. c'est peut-être ce qui empêche l'opération.
 
Dernière édition:
Je n'ai eu recours au Terminal que parce que toutes les manœuvres habituelles ne fonctionnaient pas.
Mais à la réflexion, le logiciel, dont j'ai chargé la nouvelle version à partir du site de l'éditeur, n'est peut-être pas à niveau pour Sierra. En regardant bien, il semble se lancer puis se refermer instantanément. Mais il n'y a aucune alerte. Je vais poser la question, car le site est plutôt vague.
Je ne comprends quand même pas pourquoi Terminal n'a pas demandé mon mot de passe administrateur, et m'a refusé la permission !
 
Salut Ours Gris

La commande de désactivation du GateKeeper doit être passée en mode root (Super-Administrateur Système) --> tu dois donc saisir :
Bloc de code:
sudo spctl --master-disable
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo = substitute user do : opérer en qualité d'utilisateur root substitué à l'user=soi) --> tape ton mot-de-passe de session (admin) à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎.

Pour répondre à Bigdidou :coucou: :
Pourquoi aller utiliser le terminal ?
Clic droit sur le logiciel, lancer le logiciel, cliquer là où il faut pour passer outre l'alerte qui s'affiche, et c'est plié.
Le logiciel devrait se lancer sans autre formalité les fois suivantes.
ce procédé est insuffisant en ce qui concerne initialement l'installation > voire ultérieurement le lancement de certaines applications considérées comme non-signées.

La commande donnée ci-dessus présente un avantage indéniable qui est le suivant : elle restaure dans le panneau Menu  > Sécurité et confidentialité > Général > option : "Autoriser les applications téléchargées de:" --> la tierce option classique :
⦿ N'importe où - option graphique qui a été retirée d'affichage par défaut dans l'OS «Sierra».

Je trouve - personnellement parlant - un procédé parfaitement odieux que celui consistant à visser d'un cran de plus à chaque OS sur le plan de la « sécurisation de la configuration du Système » sous prétexte d'une aggravation incessante des menaces exogènes diffuses pesant sur la naïveté de l'utilisateur. Après le kext_signing de «Yosemite» > puis le SIP d'«El Capitan» > le blocage graphique du GateKeeper de «Sierra»... Chaque fois > l'obligation de passer par le «Terminal» pour restaurer la latitude d'opération à l'ancienne. On ne peut pas proclamer servir la liberté de l'utilisateur en dérobant à cette liberté ses moyens de choix et sa responsablité, càd. en la confinant à un espace opératoire de plus en plus protégé et sécurisé par autrui. Tout en réservant uniquement aux plus experts (utilisateurs du «Terminal») la capacité de récupérer la liberté plénière dont est privée par défaut la masse des utilisateurs du mode graphique. Une telle discrimination a priori porte le nom d'« injustice ».

Bref... l'avantage de passer la commande ci-dessus dans le «Terminal» > est de restaurer l'option graphique tierce dans le panneau Sécurité et confidentialité : ainsi, l'utilisateur peut-il à la volée, en mode graphique parfaitement manipulable sans prise de tête "terminale", sélectionner la 3è option pour l'installation d'une application controversée par le Système > puis revenir après coup à la 2è (Mac App Store & développeurs identifiés) comme standard de son Système s'il le souhaite.
 
Merci macomaniac pour cette longue et claire explication détaillée de la différence entre clic droit / Ouvrir et la commande en mode texte (que tu affectionne particulièrement ;) :coucou: )
 
Merci Macomaniac, une fois toutes mes conneries corrigées, le choix de "n'importe où" est bien disponible à tout moment.
Mais mon appli de compta, qui marchait à la perfection sous 10.11, ne s'ouvre toujours pas sous 10.12, bien qu'il s'agisse de la même version. C'est un logiciel OpenSource toutes plateformes, je peux comprendre que l'adaptation prenne du temps.
Je vais réfléchir à revenir à El Capitan au moins sur une machine, mais c'est du boulot et quelques risques.

D'accord avec toi, Apple devient paranoïaque et prend tous ses clients pour des incapables irresponsables.
J'aimais beaucoup l'approche anglaise il y a 50 ans : on explique bien aux gens tout ce qu'il risquent, ensuite c'est à chacun de prendre ses responsabilités, tant pis pour lui s'il en meurt. Peu d'interdiction, peu de barrières mais des explications pour adultes.
Il est vrai que, jusqu'à présent, les Anglais savaient lire, n'étaient pas trop maternés après l'âge de 3 ans… et qu'on pouvait donc leur dire plus souvent la vérité plutôt que de les endormir (enfumer ?) avec des choses agréables.
 
:coucou: Ours Gris

Ah ! les jardins à l'Anglaise en regard des jardins à la Française. Qui croirait que ces Anglais, si formalistes (voire victoriens) quant aux protocoles sociaux, jouissent autant des désordres de la nature ?-
361608_original.png


Mais mon appli de compta, qui marchait à la perfection sous 10.11, ne s'ouvre toujours pas sous 10.12, bien qu'il s'agisse de la même version.

Puisque le Janitor n'est plus en cause > ce doit être parce que ton application n'a pas été mise à niveau pour «Sierra» - non ?
 
3 semaines plus tard, ski oblige, après avoir installé Yosemite sur un disque vierge, le verdict est tombé : c'est le portage sur Mac de mon appli de compta qui foire, dans sa nouvelle version majeure. Ça fonctionne sur Windows, et l'éditeur ne répond pas sans contrat d'assistance…
Je change donc de logiciel, ce qui ne ce fait pas d'un clic, qu'il soit droit ou gauche.
Un grand merci.
 
:coucou: Ours Gris

Après des vacances de ski > avec le printemps devant soi --> c'est le moment opportun pour abandonner quelques routines-
361608_original.png
 
Salut Ours Gris

La commande de désactivation du GateKeeper doit être passée en mode root (Super-Administrateur Système) --> tu dois donc saisir :
Bloc de code:
sudo spctl --master-disable
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo = substitute user do : opérer en qualité d'utilisateur root substitué à l'user=soi) --> tape ton mot-de-passe de session (admin) à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎.

Pour répondre à Bigdidou :coucou: :

ce procédé est insuffisant en ce qui concerne initialement l'installation > voire ultérieurement le lancement de certaines applications considérées comme non-signées.

La commande donnée ci-dessus présente un avantage indéniable qui est le suivant : elle restaure dans le panneau Menu  > Sécurité et confidentialité > Général > option : "Autoriser les applications téléchargées de:" --> la tierce option classique :
⦿ N'importe où - option graphique qui a été retirée d'affichage par défaut dans l'OS «Sierra».

Je trouve - personnellement parlant - un procédé parfaitement odieux que celui consistant à visser d'un cran de plus à chaque OS sur le plan de la « sécurisation de la configuration du Système » sous prétexte d'une aggravation incessante des menaces exogènes diffuses pesant sur la naïveté de l'utilisateur. Après le kext_signing de «Yosemite» > puis le SIP d'«El Capitan» > le blocage graphique du GateKeeper de «Sierra»... Chaque fois > l'obligation de passer par le «Terminal» pour restaurer la latitude d'opération à l'ancienne. On ne peut pas proclamer servir la liberté de l'utilisateur en dérobant à cette liberté ses moyens de choix et sa responsablité, càd. en la confinant à un espace opératoire de plus en plus protégé et sécurisé par autrui. Tout en réservant uniquement aux plus experts (utilisateurs du «Terminal») la capacité de récupérer la liberté plénière dont est privée par défaut la masse des utilisateurs du mode graphique. Une telle discrimination a priori porte le nom d'« injustice ».

Bref... l'avantage de passer la commande ci-dessus dans le «Terminal» > est de restaurer l'option graphique tierce dans le panneau Sécurité et confidentialité : ainsi, l'utilisateur peut-il à la volée, en mode graphique parfaitement manipulable sans prise de tête "terminale", sélectionner la 3è option pour l'installation d'une application controversée par le Système > puis revenir après coup à la 2è (Mac App Store & développeurs identifiés) comme standard de son Système s'il le souhaite.
salut salut déjà merci pour ton explication mais mon problème ici est que lorsque je rentre la commande sudo spctl --master-disable rien ne se passe a part "command not found" ... peut on m'aider merci beaucoup!
 
Salut caillou

Passe la commande :
Bloc de code:
whereis spctl

  • qui s'enquiert de la localisation dans l'OS de l'exécutable spctl (system_policy_control : contrôle de la police du Système)

=> qu'est-ce que tu obtiens comme retour ?
 
  • J’aime
Réactions: caillou0201
Whaaaa !
361608_original.png


Tu n'as l'air d'avoir aucun dossier d'exécutables inscrit dans tes préférences (variable $PATH) --> ce qui permet à un utilsateur d'appeler directement un utilitaire (genre : ls pour lister ou whereis pour savoir où est tel exécutable) sans avoir besoin chaque fois de renseigner le chemin absolu qui y mène. C'est une affaire de commodité. Au lieu d'avoir à écrire :
Bloc de code:
/bin/ls /
  • pour lister les objets de l'espace-racine du volume démarré > ce qui serait pénible parce que je devrais me souvenir que l'utilitaire ls est dans le dossier /bin --> je me contente d'écrire :
Bloc de code:
ls /
(je n'ai besoin que de garder en mémoire le nom de l'utilitaire > pas son emplacement) et ça marche. Parce que le dossier /bin fait (entre autre) partie de mes préférences $PATH.

----------

Pour ce qui est de la commande spécifique que tu souhaites passer --> passe-la ainsi pour voir :
Bloc de code:
/usr/bin/sudo /usr/sbin/spctl --master-disable

  • en t'authentifiant à l'aveugle avec ton mot-de-passe de session admin à la demande de password et en revalidant
 
Whaaaa !
361608_original.png


Tu n'as l'air d'avoir aucun dossier d'exécutables inscrit dans tes préférences (variable $PATH) --> ce qui permet à un utilsateur d'appeler directement un utilitaire (genre : ls pour lister ou whereis pour savoir où est tel exécutable) sans avoir besoin chaque fois de renseigner le chemin absolu qui y mène. C'est une affaire de commodité. Au lieu d'avoir à écrire :
Bloc de code:
/bin/ls /
  • pour lister les objets de l'espace-racine du volume démarré > ce qui serait pénible parce que je devrais me souvenir que l'utilitaire ls est dans le dossier /bin --> je me contente d'écrire :
Bloc de code:
ls /
(je n'ai besoin que de garder en mémoire le nom de l'utilitaire > pas son emplacement) et ça marche. Parce que le dossier /bin fait (entre autre) partie de mes préférences $PATH.

----------

Pour ce qui est de la commande spécifique que tu souhaites passer --> passe-la ainsi pour voir :
Bloc de code:
/usr/bin/sudo /usr/sbin/spctl --master-disable

  • en t'authentifiant à l'aveugle avec ton mot-de-passe de session admin à la demande de password et en revalidant
meerrcciii cela fonctionne maintenant :)
 
Mais tu as un problème de « variable $PATH » (préférences de dossiers d'exécutables appelables automatiquement sans avoir à mentionner leur chemin). J'y reviendrai dans un moment plus loisible.