Le Mac qui vous connecte et ne vous montre rien

Un client ouvre son Mac dans le navigateur. La connexion réussit. Le nom d’utilisateur et le mot de passe sont acceptés. Puis l’écran est noir. Pas d’erreur, pas de déconnexion. Noir, avec un curseur de souris qui bouge.

Chaque journal dit que la machine va bien. Le service de partage d’écran tourne. Le compte s’authentifie. La session est déverrouillée. Disque, CPU et mémoire sont normaux. Rien, nulle part, ne signale de problème.

Cela nous a coûté plusieurs jours. Voici ce que c’était vraiment, et pourquoi les façons évidentes de le tester sont pires qu’inutiles.

Toutes les pistes évidentes sont fausses

Un Mac sans écran qui affiche du noir a une liste de suspects bien connue. Nous les avons tous passés en revue.

• Aucun écran branché. Le conseil habituel est un faux adaptateur HDMI. Nous en avons acheté. Aucun changement.
• La résolution. Un Mac sans écran peut démarrer avec une taille que certains clients n’aiment pas. Ce n’était pas ça.
• Le verrouillage de l’écran. Une session verrouillée peut afficher du noir. La session était déverrouillée.
• L’affichage lui-même. Nous avons branché un vrai moniteur sur un vrai Mac mini. L’écran physique était noir lui aussi.

C’est ce dernier point qui a réorienté la recherche. La machine n’échouait pas à envoyer une image à un client distant. Il n’y avait pas d’image.

Tourner n’est pas la même chose qu’être autorisé

Notre script de provisionnement active le partage d’écran de la seule façon qui marche sans personne devant la machine :

launchctl enable system/com.apple.screensharing
launchctl bootstrap system   /System/Library/LaunchDaemons/com.apple.screensharing.plist

Cela démarre le service. Depuis macOS 14, le propre kickstart -activate d’Apple refuse de tourner sans écran. C’est donc ce qui reste.

Mais démarrer le service ne revient pas à lui donner le droit d’enregistrer l’écran. L’enregistrement de l’écran est un privilège TCC. macOS l’accorde de deux façons exactement. Soit un humain active le partage d’écran dans Réglages Système et s’authentifie, soit un MDM pousse un profil PPPC.

Sans cette autorisation, le service tourne quand même. Il écoute toujours sur le port 5900. Il accepte toujours votre mot de passe. Il n’a simplement rien qu’il ait le droit de vous montrer.

macOS vous le dira, si vous lui posez la bonne question :

$ sudo .../ARDAgent.app/Contents/Resources/kickstart     -configure -access -on -users runner -privs -all

Screen recording might be disabled. Screen Sharing or Remote
Management must be enabled from System Settings or via MDM.

Pourquoi nous ne l’avons pas trouvé plus tôt

C’est la partie qui mérite d’être transmise. Le problème n’était pas que la réponse soit cachée. C’était que chaque moyen rapide de vérifier nous disait que tout allait bien.

screencapture en SSH échoue toujours. Lancez-le dans une session SSH et TCC le refuse, que le privilège soit accordé ou non. Il ne distingue pas une machine cassée d’une machine qui marche. Chaque résultat qu’il nous a donné n’était que du bruit.

La sonde kickstart réussit quand elle n’a aucun privilège. Sans droits suffisants, elle n’affiche rien du tout. Un code qui prend une sortie vide pour une absence d’avertissement y lit un succès. Le nôtre l’a fait.

Les deux vérifications ont un point commun : leur sortie en cas d’échec est identique à leur sortie en cas de succès. Une vérification pareille n’est pas une preuve faible. Ce n’est aucune preuve, déguisée en réassurance.

Mesurer l’image

Le seul test fiable porte sur ce que voit le client. Nous nous connectons comme un vrai client VNC, nous récupérons un rectangle du framebuffer, et nous le mesurons. Un bureau noir, c’est deux couleurs à une luminosité proche de zéro. Un bureau qui marche, non.

desktop        : Mac mini  1920x1080  32bpp depth24
sampled        : 273768 pixels from 1 rect(s)
mean brightness: 36.31%
distinct colours: 93828
RESULT: REAL PICTURE

Quatre-vingt-treize mille couleurs distinctes, c’est un bureau. Deux, c’est un échec. Aucune interprétation n’est nécessaire, et il n’y a pas de code de sortie à mal lire. Ce test tourne désormais sur chaque machine avant qu’un client ne puisse s’en approcher.

La correction, et ce qu’elle coûte

Sur une machine, la correction prend dix secondes. Ouvrez Réglages Système, Général, Partage. Désactivez le partage d’écran. Réactivez-le. Il demande un mot de passe administrateur, et c’est justement cette authentification qui compte. L’interrupteur paraît en général déjà activé, car le script a démarré le service. C’est le fait de le basculer quand même qui accorde le privilège.

L’autorisation est au niveau du système. Elle survit donc à l’effacement de la machine entre deux clients. Nous l’avons vérifié en effaçant une machine puis en contrôlant de nouveau.

Le vrai coût, c’est qu’il faut un humain devant la machine, une fois. C’est la seule étape manuelle d’un processus par ailleurs entièrement scripté. À l’échelle d’un parc, la réponse est un profil de configuration MDM qui accorde le privilège dès le départ. C’est la bonne correction. Et c’est la seule chose qu’aucun script ne peut contourner sur un Mac pas encore inscrit.

Si vous automatisez des Mac

Deux leçons méritent d’être retenues, et une seule concerne l’enregistrement de l’écran.

La première : macOS a une catégorie d’état qu’un script ne peut pas atteindre. Les privilèges TCC sont volontairement protégés par un humain au clavier ou par un profil MDM. Si votre automatisation suppose qu’elle peut tout configurer, elle finira par produire une machine qui a l’air prête et ne l’est pas.

La seconde est plus générale. Avant d’écrire une vérification, demandez-vous ce qu’elle affiche quand la chose est cassée. Si c’est la même chose que quand elle marche, la vérification ne vaut rien. Elle vous coûtera plus de temps que pas de vérification du tout. Nous en avions deux comme ça, et c’est à cause d’elles que cela a pris des jours au lieu d’un après-midi.