10.13 High Sierra me remettre en admin...
- Créateur du sujet Camelote
- Date de début
- Statut
M
Membre supprimé 1060554
Invité
J'ai fait un petit test dans une session Admin expérimentale.
L'utilisateur a pour Nom complet (nom long) : coco > et pour Nom du compte (nom court) : coco. Donc pareil.
Dans la session coco ouverte --> je déverrouille le panneau des Utilisateurs et groupes > je presse la touche ctrl tout en sélectionnant coco > et j'obtiens le panneau des Options avancées qui représente (en abrégé) la carte d'identité de l'utilisateur (un fichier coco.plist recelé dans la base de données users du Service d'Annuaire).
Je modifie le Nom complet > de coco --> à coco polo > ce qui est validé quand je presse le bouton OK. Dans la panneau des Utilisateurs et groupes (qui affiche toujours les Noms complets et pas les noms courts des utilisateurs) --> je vois s'afficher un coco polo > lequel garde son label : Admin.
Je modifie le nom court > de coco --> à cocopolo. L'édition est apparemment enregistrée quand je presse le bouton OK => mais ! immédiatement le label Admin de l'utilisateur est viré à Standard. Un sous-panneau annonce qu'il faut re-démarrer pour que la modification soit prise en compte. Le cadenas du panneau des Utilisateurs et groupes étant toujours déverrouillé --> je peux recocher la case : "Autorisation à administrer cet ordinateur" qui avait été décochée.
Je re-démarre et je me relogge dans la session coco polo (la modification du Nom complet a été enregistrée). J'inspecte le panneau des Utilisateurs et groupes --> quoique ayant recoché la case : "Autorisation à administrer cet ordinateur" > le label sous coco polo (Nom complet) est toujours Standard. Si j'inspecte la carte d'identité de l'utilisateur (en déverrouillant le cadenas avec un autre identifiant de compte Admin) --> le nom court est resté coco = aucune modification n'a été enregistrée.
----------
Contre-test 1 : dans ma session Admin macomaniac > je déverrouille le panneau des Utilisateurs et groupes > j'accède à la carte d'identité de coco polo (Nom complet modifié de l'utilisateur) > je modifie le nom court coco --> cocopolo et je presse le bouton OK. Le changement de nom court est enregistré > sans que le label Admin de l'utilisateur (que j'avais restauré au préalable) ne soit modifié.
----------
Contre-test 2 : dans une session coco (Admin) de l'OS Sierra --> il est possible de modifier le nom court (nom du compte) à cocopolo sans modification du label : Admin. En se déloggeant de la session > se reloggeant comme coco (Nom complet) --> l'utilisateur est toujours Admin. Une inspection de sa carte d'identité montre que la modification nom court a bien été enregistrée.
----------
Conclusion : on a donc bien affaire à un bogue spécifique de High Sierra > qui dégrade de Admin à Standard tout utilisateur qui esquisse une modification de son nom court dans le panneau des Utilisateurs et groupes > en accédant à sa carte d'identité (Options avancées). Cette esquisse de modification ne donne lieu à aucune modification du nom court > mais uniquement à cette dégradation de statut.
Ce bogue va à l'encontre de toute la tradition OS X => prolongée par macOS Sierra : à savoir --> un utilisateur à le pouvoir et il a aussi le droit > en accédant à sa carte d'identité des Préférences Système > de modifier en mode "live" aussi bien son Nom complet (nom long) que son nom du compte (nom court) => le statut Admin n'est pas affecté > et la modification notamment du nom court est immédiate (prise en compte par simple déloggement de session sans redémarrage).
Il est clair que dans High Sierra un daemon auxiliaire de l'Open Directory (Service d'Annuaire) loupe le coche. On tient ici la raison de l'avalanche de plaignants sur le forum macOS > qui attestent avoir perdu leur statut Admin. Ce bogue est spécifique de l'OS High Sierra. Dans aucun des OS précédents un utilisateur modifiant en mode "live" (dans sa propre session ouverte) son Nom complet et surtout son nom court (Nom du compte) ne s'exposait à une dégradation de statut Admin --> Standard. La modification était bien energistrée "à la volée" sans aucun impact > et prenait effet au reloggement.
Le bogue de High Sierra n'est toujours pas corrigé dans la version développeur 10.13.5. Je conjecture qu'il ne le sera pas dans toute la carrière publique de cet OS.
Il ne faut donc pas culpabiliser les utilisateurs qui usent du pouvoir et du droit qui leur est imparti de modifier en mode "live" (session ouverte, utilisateur connecté) leurs noms (complet et ou court) dans le panneau des Utilisateurs et groupes. Cette sorte d'action était parfaitement gérée dans les OS antérieurs à 10.13 sans aucun impact négatif > et ne suscitait aucun retour problématique.
On peut conseiller d'intervenir à partir d'une autre session Admin ouverte que la session impliquée --> mais il s'agit là du palliatif d'un bogue spécifique de High Sierra.
L'utilisateur a pour Nom complet (nom long) : coco > et pour Nom du compte (nom court) : coco. Donc pareil.
Dans la session coco ouverte --> je déverrouille le panneau des Utilisateurs et groupes > je presse la touche ctrl tout en sélectionnant coco > et j'obtiens le panneau des Options avancées qui représente (en abrégé) la carte d'identité de l'utilisateur (un fichier coco.plist recelé dans la base de données users du Service d'Annuaire).
Je modifie le Nom complet > de coco --> à coco polo > ce qui est validé quand je presse le bouton OK. Dans la panneau des Utilisateurs et groupes (qui affiche toujours les Noms complets et pas les noms courts des utilisateurs) --> je vois s'afficher un coco polo > lequel garde son label : Admin.
Je modifie le nom court > de coco --> à cocopolo. L'édition est apparemment enregistrée quand je presse le bouton OK => mais ! immédiatement le label Admin de l'utilisateur est viré à Standard. Un sous-panneau annonce qu'il faut re-démarrer pour que la modification soit prise en compte. Le cadenas du panneau des Utilisateurs et groupes étant toujours déverrouillé --> je peux recocher la case : "Autorisation à administrer cet ordinateur" qui avait été décochée.
Je re-démarre et je me relogge dans la session coco polo (la modification du Nom complet a été enregistrée). J'inspecte le panneau des Utilisateurs et groupes --> quoique ayant recoché la case : "Autorisation à administrer cet ordinateur" > le label sous coco polo (Nom complet) est toujours Standard. Si j'inspecte la carte d'identité de l'utilisateur (en déverrouillant le cadenas avec un autre identifiant de compte Admin) --> le nom court est resté coco = aucune modification n'a été enregistrée.
----------
Contre-test 1 : dans ma session Admin macomaniac > je déverrouille le panneau des Utilisateurs et groupes > j'accède à la carte d'identité de coco polo (Nom complet modifié de l'utilisateur) > je modifie le nom court coco --> cocopolo et je presse le bouton OK. Le changement de nom court est enregistré > sans que le label Admin de l'utilisateur (que j'avais restauré au préalable) ne soit modifié.
----------
Contre-test 2 : dans une session coco (Admin) de l'OS Sierra --> il est possible de modifier le nom court (nom du compte) à cocopolo sans modification du label : Admin. En se déloggeant de la session > se reloggeant comme coco (Nom complet) --> l'utilisateur est toujours Admin. Une inspection de sa carte d'identité montre que la modification nom court a bien été enregistrée.
----------
Conclusion : on a donc bien affaire à un bogue spécifique de High Sierra > qui dégrade de Admin à Standard tout utilisateur qui esquisse une modification de son nom court dans le panneau des Utilisateurs et groupes > en accédant à sa carte d'identité (Options avancées). Cette esquisse de modification ne donne lieu à aucune modification du nom court > mais uniquement à cette dégradation de statut.
Ce bogue va à l'encontre de toute la tradition OS X => prolongée par macOS Sierra : à savoir --> un utilisateur à le pouvoir et il a aussi le droit > en accédant à sa carte d'identité des Préférences Système > de modifier en mode "live" aussi bien son Nom complet (nom long) que son nom du compte (nom court) => le statut Admin n'est pas affecté > et la modification notamment du nom court est immédiate (prise en compte par simple déloggement de session sans redémarrage).
Il est clair que dans High Sierra un daemon auxiliaire de l'Open Directory (Service d'Annuaire) loupe le coche. On tient ici la raison de l'avalanche de plaignants sur le forum macOS > qui attestent avoir perdu leur statut Admin. Ce bogue est spécifique de l'OS High Sierra. Dans aucun des OS précédents un utilisateur modifiant en mode "live" (dans sa propre session ouverte) son Nom complet et surtout son nom court (Nom du compte) ne s'exposait à une dégradation de statut Admin --> Standard. La modification était bien energistrée "à la volée" sans aucun impact > et prenait effet au reloggement.
Le bogue de High Sierra n'est toujours pas corrigé dans la version développeur 10.13.5. Je conjecture qu'il ne le sera pas dans toute la carrière publique de cet OS.
Il ne faut donc pas culpabiliser les utilisateurs qui usent du pouvoir et du droit qui leur est imparti de modifier en mode "live" (session ouverte, utilisateur connecté) leurs noms (complet et ou court) dans le panneau des Utilisateurs et groupes. Cette sorte d'action était parfaitement gérée dans les OS antérieurs à 10.13 sans aucun impact négatif > et ne suscitait aucun retour problématique.
On peut conseiller d'intervenir à partir d'une autre session Admin ouverte que la session impliquée --> mais il s'agit là du palliatif d'un bogue spécifique de High Sierra.
Dernière édition par un modérateur:
Sauf que les "aventureux" en question, viennent chercher de l'aide quand il est déjà trop tard.
Tant que le bug n'est pas corrigé par Apple (mais ils ne semblent pas pressé de le faire alors qu'ils ont diffusé un processus de résolution aux Genius des AppleStore, donc ils sont bien au courant), on aura encore à prendre en main ces malheureux pour leur redonner le droit d'administrer leur Mac.
@macomaniac
Dans ton exemple, tu modifies le nom de compte (ce que tu appelles le nom court) dans la foulée de la modification du nom complet. Or, il est expressément indiqué dans la documentation Apple de le faire à partir d’une autre session administratrice autre, compte à modifier fermé.
Tu démontres simplement qu’en faisant n’importe quoi on obtient n’importe quoi. Conclusion : bullshit.
J’ai SCRUPULEUSEMENT suivi la procédure données par Apple. Et le compte administrateur dont j’ai modifié, dans un premier temps, le nom complet, puis dans un deuxième temps, à partir d’un autre compte administrateur, le nom de compte et le nom du dossier de départ, à chacune de ces étapes, le compte modifié a conservé son statut administrateur.
Bref, vous ne racontez que des conneries. Il n’y a pas de bug, il n’y a que des bozos incapables de suivre une procédure parfaitement détaillée.
Dans ton exemple, tu modifies le nom de compte (ce que tu appelles le nom court) dans la foulée de la modification du nom complet. Or, il est expressément indiqué dans la documentation Apple de le faire à partir d’une autre session administratrice autre, compte à modifier fermé.
Tu démontres simplement qu’en faisant n’importe quoi on obtient n’importe quoi. Conclusion : bullshit.
J’ai SCRUPULEUSEMENT suivi la procédure données par Apple. Et le compte administrateur dont j’ai modifié, dans un premier temps, le nom complet, puis dans un deuxième temps, à partir d’un autre compte administrateur, le nom de compte et le nom du dossier de départ, à chacune de ces étapes, le compte modifié a conservé son statut administrateur.
Bref, vous ne racontez que des conneries. Il n’y a pas de bug, il n’y a que des bozos incapables de suivre une procédure parfaitement détaillée.
S'il y a des bozos c'est parmis les développeurs de MacOS.
Il n'y a AUCUNE raison valable pour que le fichier plist correspondant à la carte d'identité de l'utilisateur dans l'open directory, situé dans private/var/db/dslocal/nodes/Default/users, voie l'argument Status passer de Admin à Standard lors de cette modification.
Il n'y a AUCUNE raison valable pour que le fichier plist correspondant à la carte d'identité de l'utilisateur dans l'open directory, situé dans private/var/db/dslocal/nodes/Default/users, voie l'argument Status passer de Admin à Standard lors de cette modification.
Mais n’importe quoi !
Si tu suis la procédure Apple, il n’y a aucun problème.
Déjà, tu as dis qu’il suffisait de changer le nom complet #13 d’un compte admin pour le faire passer en standard.
Faux ! J’ai changé le nom complet d’un compte administrateur (macOS 10.13.4) et ce compte a conservé son statut administrateur.
Ensuite, j’ai changé le nom de compte, à partir d’un autre compte administrateur, le compte à modifier étant fermé — et c’est peut-être là que vous vous plantez — et le nom du dossier de départ (il faut faire les deux, et en premier le nom du dossier de départ), toujours selon les indications données par Apple.
Et le compte administrateur est resté un compte administrateur.
Observation : chez moi, le répertoire /private/var/db/dslocal/nodes est un dossier verrouillé accessible uniquement à root. Pour dire aussi combien je me fous de ce qui s’y passe.
L’admin reste admin, le standart reste standart et le reste est du mauvais roman.
et c'est bien parce que tu ne comprends rien à la façon dont sont gérés les utilisateurs au sein d'OpenDirectory que tu ne peux pas comprendre qu'il y a réellement un bug apparu avec HighSierra.
Il y a d'une part un défaut d'ergonomie, les champs ne devant pas être modifiés devraient être verrouillés, voire ne pas être présentés du tout à l'utilisateur, et d'autre part un bug qui modifie la valeur du paramètre de statut dans le plist au moment du réenregistrement du plist.
M
Membre supprimé 1060554
Invité
J'ai repris patiemment mes tests : dans tous les OS X Intel de «Lion 10.7» à «El Capitan 10.7» et aussi dans macOS Sierra 10.12 -->
un utilisateur Admin qui s'appelait cette fois-ci bibi (nom court) peut en mode "live" (sa session ouverte) éditer son nom court bibi dans le panneau des Préférences Système à bibibibi (c'est l'exemple que je me suis donné). Cette modification live n'affecte en rien son statut Admin. Après déloggement / reloggement --> il est toujours Admin > et son nom court est devenu bibibibi. Une commande :
atteste que le fichier bibi.plist qui faisait exister l'utilisateur bibi pour le Système > est devenu bibibibi.plist > ce qui fait que le Système reconnait désormais un utilisateur bibibibi et plus aucun bibi. Sans modification du nom du dossier de départ (qui reste intitulé bibi) > la session s'ouvre sans aucun problème > l'adresse au dossier de départ demeurant /Users/bibi dans le fichier carte d'identité de l'utilisateur bibibibi.plist.
Ces expériences montrent qu'il n'y aucun problème pour un utilisateur à modifier son nom court (le plus critique car intitulé du fichier "carte d'identité - le nom long étant sans importance) dans sa propre session ouverte (en mode live) --> dans tous les OS avant High Sierra > cette action étant immédiatement répercutée sans perte de statut Admin.
Dans l'OS High Sierra seul --> un utilisateur bibi qui esquisse dans les Utilisateurs et groupes une modification de son nom court --> voit aussitôt son statut dégradé de Admin à Standard > sans qu'aucune modification du nom court ne soit réellement prise en compte. Le fichier carte d'identité reste intitulé bibi.plist et donc l'utilisateur existe pour le Système en tant que bibi.
----------
Nous avons donc affaire à une action qui était non seulement possible dans tous les OS antérieurs > mais aussi légitimée par le Système (qui répercutait immédiatement la modification du nom court) > et dépourvue de sanction dégradant le statut de Admin à Standard. Dans le seul OS High Sierra > cette action est toujours formellement possible dans les mêmes conditions (en mode live : session ouverte) > mais non légitimée par le Système (qui ne la répercute pas) > et surtout cette action non enregistrée par le Système se trouve sanctionnée par une dégradation de Admin à Standard. Qu'une action non enregistrée par le Système ait un effet pervers de dégradation de statut : c'est un véritable bogue. Une erreur de programmation évidente.
Le daemon de l'Open Directory qui gère en service continu les bases de données des utilisateurs et des groupes -->
Cette contradiction de comportement du daemon de l'Open Directory est une erreur logique interne de sa programmation. En aucun cas, forme, mesure ni figure, un même daemon ne devrait rejeter une modification nominale adressée à un fichier bibi.plist de la base de données users > et accepter cette modification en rayant le nom original bibi du fichier admin.plist de la base de données groups. C'est formellement inacceptable. Car pour supprimer bibi du fichier admin.plist (base de données du groupe Admin) > le daemon accepte la cessation d'existence d'une identité d'utilisateur bibi. Or en même temps il la refuse, puisqu'il ne modifie pas le fichier bibi.plist de la base de données des users > et donc continue de faire exister bibi pour le Système.
Il est inacceptable logiquement que bibi soit à la fois considéré comme existant (en tant qu'utilisateur) et soit considéré comme inexistant (en tant qu'utilisateur) et par là supprimé d'office dans le fichier admin.plist qui liste les utilisateurs Admin.
En remontant des « effets » (dégradation de statut) à la « raison des effets » (contradiction logique bibi existe / bibi n'existe pas) --> il est absolument évident qu'il faut parler d'un bogue de programmation du daemon de l'Open Directory.
un utilisateur Admin qui s'appelait cette fois-ci bibi (nom court) peut en mode "live" (sa session ouverte) éditer son nom court bibi dans le panneau des Préférences Système à bibibibi (c'est l'exemple que je me suis donné). Cette modification live n'affecte en rien son statut Admin. Après déloggement / reloggement --> il est toujours Admin > et son nom court est devenu bibibibi. Une commande :
Bloc de code:
sudo ls /private/var/db/dslocal/nodes/Default/users | sed '/^_/ d'- qui liste les fichiers "cartes d'identités" d'utilisateurs de type "personnel" (sans underscore initial _)
atteste que le fichier bibi.plist qui faisait exister l'utilisateur bibi pour le Système > est devenu bibibibi.plist > ce qui fait que le Système reconnait désormais un utilisateur bibibibi et plus aucun bibi. Sans modification du nom du dossier de départ (qui reste intitulé bibi) > la session s'ouvre sans aucun problème > l'adresse au dossier de départ demeurant /Users/bibi dans le fichier carte d'identité de l'utilisateur bibibibi.plist.
Ces expériences montrent qu'il n'y aucun problème pour un utilisateur à modifier son nom court (le plus critique car intitulé du fichier "carte d'identité - le nom long étant sans importance) dans sa propre session ouverte (en mode live) --> dans tous les OS avant High Sierra > cette action étant immédiatement répercutée sans perte de statut Admin.
Dans l'OS High Sierra seul --> un utilisateur bibi qui esquisse dans les Utilisateurs et groupes une modification de son nom court --> voit aussitôt son statut dégradé de Admin à Standard > sans qu'aucune modification du nom court ne soit réellement prise en compte. Le fichier carte d'identité reste intitulé bibi.plist et donc l'utilisateur existe pour le Système en tant que bibi.
----------
Nous avons donc affaire à une action qui était non seulement possible dans tous les OS antérieurs > mais aussi légitimée par le Système (qui répercutait immédiatement la modification du nom court) > et dépourvue de sanction dégradant le statut de Admin à Standard. Dans le seul OS High Sierra > cette action est toujours formellement possible dans les mêmes conditions (en mode live : session ouverte) > mais non légitimée par le Système (qui ne la répercute pas) > et surtout cette action non enregistrée par le Système se trouve sanctionnée par une dégradation de Admin à Standard. Qu'une action non enregistrée par le Système ait un effet pervers de dégradation de statut : c'est un véritable bogue. Une erreur de programmation évidente.
Le daemon de l'Open Directory qui gère en service continu les bases de données des utilisateurs et des groupes -->
- d'un côté n'enregistre pas la modification bibi --> bibibibi en ce qui conserne la base de données des utilisateurs (at: /private/var/db/dslocal/nodes/Default/users)
- mais d'un autre côté enregistre cette modification en désenregistrant bibi dans le fichier admin.plist de la base de données des groupes (at: /private/var/db/dslocal/nodes/Default/groups).
Cette contradiction de comportement du daemon de l'Open Directory est une erreur logique interne de sa programmation. En aucun cas, forme, mesure ni figure, un même daemon ne devrait rejeter une modification nominale adressée à un fichier bibi.plist de la base de données users > et accepter cette modification en rayant le nom original bibi du fichier admin.plist de la base de données groups. C'est formellement inacceptable. Car pour supprimer bibi du fichier admin.plist (base de données du groupe Admin) > le daemon accepte la cessation d'existence d'une identité d'utilisateur bibi. Or en même temps il la refuse, puisqu'il ne modifie pas le fichier bibi.plist de la base de données des users > et donc continue de faire exister bibi pour le Système.
Il est inacceptable logiquement que bibi soit à la fois considéré comme existant (en tant qu'utilisateur) et soit considéré comme inexistant (en tant qu'utilisateur) et par là supprimé d'office dans le fichier admin.plist qui liste les utilisateurs Admin.
En remontant des « effets » (dégradation de statut) à la « raison des effets » (contradiction logique bibi existe / bibi n'existe pas) --> il est absolument évident qu'il faut parler d'un bogue de programmation du daemon de l'Open Directory.
Dernière édition par un modérateur:
J'ai retesté... effectivement, je pensais modifier le nom complet, mais c'est le nom abrégé que je modifiais (il faut que je change mes comptes de tests que j'appelle systématiquement toto, ce qui donne la même chose pour nom complet et nom abrégé)
Donc le problème est bien sur le nom de compte aka nom abrégé et pas sur le nom complet.
Donc la procédure Apple doit être suivie : c’est-à-dire deuxième compte administrateur.
Et toi, tu comprends si bien que tu ne sais plus faire la différence entre le nom complet et le nom de compte.
Il n’y a qu’une chose à comprendre : QUAND ON SUIT LA PROCEDURE DONNÉE PAR APPLE ON N’A PAS DE PROBLÈMES.
@macomaniac
La question n’est pas est-ce que vos bricolages marchent avec les systèmes précédents.
La question est de savoir si High Sierra change un compte administrateur en compte standard quand on suit la procédure normale, celle donnée par Apple.
Le reste c’est de branlette.
Au passage, je me permets de le souligner de nouveau : s'intéresser d'aussi près aux fichiers .plist utilisés par l'annuaire pour stocker ses informations est une mauvaise idée. Il ne faut surtout pas y toucher mais passer par les commandes fournies (ici, c'est surtout dscl).
Certes, cela pourrait être pratique dans certains cas mais, de fait, on n'en a nullement besoin... Et on risque de mettre un gros bazar involontairement.
PS : c'est comme cette manie de débloquer les sessions root, qui ne sert de rien.
Certes, cela pourrait être pratique dans certains cas mais, de fait, on n'en a nullement besoin... Et on risque de mettre un gros bazar involontairement.
PS : c'est comme cette manie de débloquer les sessions root, qui ne sert de rien.
Mais Apple donne accès à ce plist et à sa modification, en mode graphique directement via Pref Système/Utilisateurs et Groupes par un clic-droit sur l'utilisateur puis "Options Avancées".
A ce stade, soit il faut qu'Apple bloque l'accès au nom abrégé si il ne souhaite plus qu'il soit modifiable, soit revenir au fonctionnement des versions précédentes qui permettaient sans conséquence aucune de le modifier ainsi.
Parce que tu penses sérieusement que l'utilisateur lambda sait ce qu'est une technote et qu'un procédure existe quelque part sur le site d'Apple...
L'utilisateur lambda, on lui présente des champs modifiables, il fait les modifications qui lui semblent pertinentes.
Je me fous de ton utilisateur « lambda ». C’est un gros nul qui ne sait pas lire.
AVERTISSEMENT
C’est pas pour faire joli qu’Apple l'a mis en rouge et majuscule.
L’utilisateur « lambda » a bien suivi une indication quelque part pour trouver le truc du ctrl-clic sur le nom de compte dans la fenêtre des Préférences système > Utilisateurs et groupes
Ce n’est pas tombé du ciel. À moins qu’il ait vu la Sainte-Vierge des geeks au fond d’une grotte, cette info sort bien de quelque part.
Quant à la notion de modification « pertinente », elle me laisse rêveur. Pourquoi ne pas changer UUID tant qu’il y est. Ça ne semble pas moins pertinent que le reste.
D’ailleurs, si l’utilisateur « lambda » change le nom de compte sans modifier avant celui du dossier de départ, sans modifier le chemin vers celui-ci, il va prendre cher, quelque soit le système en cause.
Il faut d’urgence arrêter de vendre des ordinateurs à des gens qui ont au mieux 90 de QI.
Il faut aussi arrêter d’excuser toutes les conneries que les gens font sur leurs machines en rejetant la faute sur Apple.
On dirait un discours de pseudo sociologue bourdieusien : jamais la responsabilité de l’individu, toujours la faute de la société.
AVERTISSEMENT
C’est pas pour faire joli qu’Apple l'a mis en rouge et majuscule.
L’utilisateur « lambda » a bien suivi une indication quelque part pour trouver le truc du ctrl-clic sur le nom de compte dans la fenêtre des Préférences système > Utilisateurs et groupes
Ce n’est pas tombé du ciel. À moins qu’il ait vu la Sainte-Vierge des geeks au fond d’une grotte, cette info sort bien de quelque part.
Quant à la notion de modification « pertinente », elle me laisse rêveur. Pourquoi ne pas changer UUID tant qu’il y est. Ça ne semble pas moins pertinent que le reste.
D’ailleurs, si l’utilisateur « lambda » change le nom de compte sans modifier avant celui du dossier de départ, sans modifier le chemin vers celui-ci, il va prendre cher, quelque soit le système en cause.
Il faut d’urgence arrêter de vendre des ordinateurs à des gens qui ont au mieux 90 de QI.
Il faut aussi arrêter d’excuser toutes les conneries que les gens font sur leurs machines en rejetant la faute sur Apple.
On dirait un discours de pseudo sociologue bourdieusien : jamais la responsabilité de l’individu, toujours la faute de la société.
M
Membre supprimé 1060554
Invité
Le style que paraît affectionner Moonwalker est la diatribe. Série de proférations exclamatives injurieuses à l'égard de deux espèces d'individus : l'immense masse des crétins occupant la position entre la chaise et le clavier des Mac, qui exercent leur liberté individuelle dans l'ignorance irresponsable des règles de l'État-Apple, et la poignée d'intellectuels qui se font leurs complices idéologiques en leur cherchant des excuses.
À l'arrière-plan de ces grossières invectives (qui me paraissent mériter l'attention de la modération), il est aisé de déceler une position politique de droite accordant la primauté aux règles sécuritaires sur les libertés individuelles, les individus se trouvant sommés de cantonner l'exercice de leur liberté à ce que les lois permettent tandis que la possibilité d'examiner de manière critique la régulation de l'État se trouve a priori frappée d'anathème.
On a donc affaire ici à un phénomène de transposition du général au particulier : d'une position politique générale au domaine particulier de l'utilisation de Mac. Dans le cadre strict d'un forum technique comme macOS, il me paraît évident que ce type d'intervention politicienne doit être absolument exclu : nous ne sommes pas ici dans un espace où l'on juge les autres à l'aune de positions politiques préconçues. Un forum technique n'est pas un tribunal où l'on fait comparaître des accusés, condamnés d'avance pour avoir agi de manière anarchique sans tenir compte de la Loi que « nul n'est censé ignorer ». Il existe un forum intitulé : Réagissez ! dédié à cette espèce de querelles idéologiques.
----------
Je pense dans mon message #32 avoir mis en lumière la situation technique que voici : une contradiction logique existe dans les ressources de l'Open Directory (le Service d'Annuaire) de High Sierra, contradiction absente de tous les OS antérieurs. Cette contradiction affecte le comportement du daemon (ou service) qui gère en mode "live" (en continu de l'initialisation de l'OS à son extinction) la situation des utilisateurs et des groupes. Cette contradiction est la suivante : lorsqu'un utilisateur tente de modifier depuis sa session ouverte son nom court (nom du compte) dans le sous-panneau des Options avancées du panneau des Utilisateurs et groupes -->
Il y a là de toute évidence pour le logicien qui s'intéresse au fonctionnement d'un Système de manière purement technique --> une contradiction en acte, qui consiste comme toutes les contradictions à affirmer et à nier simultanément la même chose. Dans notre cas de figure : le daemon (qui est en somme le serviteur toujours en service des ressources de l'Open Directory) affirme le maintien d'existence de l'utilisateur machin (en refusant d'enregistrer la modification d'intitulé dans la base de données users) > et nie ce maintien d'existence de l'utilisateur machin (en rayant machin du tableau Admin dans la base de données groups).
Les utilisateurs de High Sierra qui se servent de la touche ctrl pour accéder au sous-panneau des Options avancées ne font que recourir à un droit que le Système OS X - macOS met à la disposition de leur liberté. Eh oui ! il s'agit d'un droit régulier que la programmation du Système accorde à la liberté des utilisateurs > la conséquence étant que l'usage de ce droit n'a rien intrinsèquement de contraire à la régulation du Système. Le panneau des Options avancées affiche graphiquement les principales valeurs (strings) associées à des clés (keys) du fichier machin.plist de l'utilisateur.
Dans tous les OS Apple jusqu'à High Sierra exclu, l'usage du droit d'édition (d'écriture) proposé par ce sous-panneau quand il s'agissait de modifier en mode "live" le nom court machin de l'utilisateur --> ne mettait à jour aucune contradiction dans le comportement du daemon de l'Open Directory : ce service à la fois et de manière cohérente modifiait le nom d'utilisateur (de machin à untel) et remplaçait dans le tableau Admin des groupes le nom du bénéficiaire machin par le nouveau nom untel --> ce qui fait que l'utilisateur modifiant son nom court ne se trouvait pas privé de son statut Admin. Cette double modification cohérente (modification du nom d'utilisateur dans le fichier "carte d'identité" de machin.plist à untel.plist & modification du nom d'utilisateur dans le fichier admin.plist du groupe Admin de machin à untel) --> assurait la sécurité de l'utilisateur dans l'exercice légitime de sa liberté.
Dans l'OS High Sierra seul, l'usage de ce même droit maintenu d'édition en mode "live" proposé par le sous-panneau des Options avancées --> donne lieu à une contradiction d'action de la part du daemon de l'Open Directory > qui d'une part maintient sans modification le fichier identitaire machin.plist & simultanément supprime machin du tableau Admin comme si l'identité machin avait cessé d'exister. Il s'agit manifestement d'une erreur de programmation faisant exister une contradiction dans un Système logique, càd. une inconsistance (ou incohérence).
----------
Un idéologue imbu du caractère sacré de l'État et appliquant indûment cette position politique au domaine de l'usage d'un Mac où le Système macOS devient un épitome de l'État de Droit, doit forcément ne pas "aimer" qu'on mette en évidence une contradiction logique à l'œuvre dans la régulation dudit Système. Comme si l'Amour Sacré de l'État empêchait l'entendement de constater une incohérence dans la régulation du Système.
Je sais bien qu'un avertissement dans le sous-panneau des Options avancées alerte l'utilisateur sur des risques éventuels liés à des modifications de paramètres de la carte d'identité d'utilisateur. Mais je signale à ceux qui soutiennent que la seule méthode légitime consiste à agir dans le sous-panneau des Options avancées d'un utilisateur machin à partir de la session Admin d'un autre utilisateur brol --> que le même avertissement s'affiche dans le panneau des Options avancées de machin. Ce qui fait que la situation de risque est a priori identique. Il n'y a donc aucun sens intrinsèque à valoriser exclusivement une manipulation indirecte sur une manipulation live. Sauf que - je le répète - une erreur de programmation dans les ressources de l'Open Directory de High Sierra seul donne lieu à une contradiction d'effets quand l'utilisateur tente de modifier en mode "live" son nom court. Je dis bien : "tente" --> puisqu'aucune modification effective du nom court n'est enregistrée. Et malgré cette non modification réelle > le daemon en service de l'Open Directory fait comme si une modification était intervenue en supprimant l'utilisateur du tableau Admin (sans le remplacer par une nouvelle identité d'utilisateur, puisque cette nouvelle identité n'as pas été enregistrée).
On ne peut pas culpabiliser des utilisateurs pour tenter de faire usage d'un droit que le Système leur accorde et qui ne produisait pas d'effets contradictoires dans la série des OS précédant High Sierra. Il convient de constater qu'il y a bien ici une faute logique de programmation du Système.
À l'arrière-plan de ces grossières invectives (qui me paraissent mériter l'attention de la modération), il est aisé de déceler une position politique de droite accordant la primauté aux règles sécuritaires sur les libertés individuelles, les individus se trouvant sommés de cantonner l'exercice de leur liberté à ce que les lois permettent tandis que la possibilité d'examiner de manière critique la régulation de l'État se trouve a priori frappée d'anathème.
On a donc affaire ici à un phénomène de transposition du général au particulier : d'une position politique générale au domaine particulier de l'utilisation de Mac. Dans le cadre strict d'un forum technique comme macOS, il me paraît évident que ce type d'intervention politicienne doit être absolument exclu : nous ne sommes pas ici dans un espace où l'on juge les autres à l'aune de positions politiques préconçues. Un forum technique n'est pas un tribunal où l'on fait comparaître des accusés, condamnés d'avance pour avoir agi de manière anarchique sans tenir compte de la Loi que « nul n'est censé ignorer ». Il existe un forum intitulé : Réagissez ! dédié à cette espèce de querelles idéologiques.
----------
Je pense dans mon message #32 avoir mis en lumière la situation technique que voici : une contradiction logique existe dans les ressources de l'Open Directory (le Service d'Annuaire) de High Sierra, contradiction absente de tous les OS antérieurs. Cette contradiction affecte le comportement du daemon (ou service) qui gère en mode "live" (en continu de l'initialisation de l'OS à son extinction) la situation des utilisateurs et des groupes. Cette contradiction est la suivante : lorsqu'un utilisateur tente de modifier depuis sa session ouverte son nom court (nom du compte) dans le sous-panneau des Options avancées du panneau des Utilisateurs et groupes -->
- le daemon n'écrit pas le nom modifié au fichier carte d'identité machin.plist de l'utilisateur en modifiant son intitulé > càd. ne fait pas exister pour le Système une nouvelle identité d'utilisateur
- le daemon écrit au fichier base de données admin.plist du groupe Admin en supprimant le nom de l'utilisateur machin du tableau Admin > comme si cette identité d'utilisateur machin avait été supprimée alors même qu'elle existe toujours comme intitulé du fichier machin.plist de la base de données des users
Il y a là de toute évidence pour le logicien qui s'intéresse au fonctionnement d'un Système de manière purement technique --> une contradiction en acte, qui consiste comme toutes les contradictions à affirmer et à nier simultanément la même chose. Dans notre cas de figure : le daemon (qui est en somme le serviteur toujours en service des ressources de l'Open Directory) affirme le maintien d'existence de l'utilisateur machin (en refusant d'enregistrer la modification d'intitulé dans la base de données users) > et nie ce maintien d'existence de l'utilisateur machin (en rayant machin du tableau Admin dans la base de données groups).
Les utilisateurs de High Sierra qui se servent de la touche ctrl pour accéder au sous-panneau des Options avancées ne font que recourir à un droit que le Système OS X - macOS met à la disposition de leur liberté. Eh oui ! il s'agit d'un droit régulier que la programmation du Système accorde à la liberté des utilisateurs > la conséquence étant que l'usage de ce droit n'a rien intrinsèquement de contraire à la régulation du Système. Le panneau des Options avancées affiche graphiquement les principales valeurs (strings) associées à des clés (keys) du fichier machin.plist de l'utilisateur.
Dans tous les OS Apple jusqu'à High Sierra exclu, l'usage du droit d'édition (d'écriture) proposé par ce sous-panneau quand il s'agissait de modifier en mode "live" le nom court machin de l'utilisateur --> ne mettait à jour aucune contradiction dans le comportement du daemon de l'Open Directory : ce service à la fois et de manière cohérente modifiait le nom d'utilisateur (de machin à untel) et remplaçait dans le tableau Admin des groupes le nom du bénéficiaire machin par le nouveau nom untel --> ce qui fait que l'utilisateur modifiant son nom court ne se trouvait pas privé de son statut Admin. Cette double modification cohérente (modification du nom d'utilisateur dans le fichier "carte d'identité" de machin.plist à untel.plist & modification du nom d'utilisateur dans le fichier admin.plist du groupe Admin de machin à untel) --> assurait la sécurité de l'utilisateur dans l'exercice légitime de sa liberté.
Dans l'OS High Sierra seul, l'usage de ce même droit maintenu d'édition en mode "live" proposé par le sous-panneau des Options avancées --> donne lieu à une contradiction d'action de la part du daemon de l'Open Directory > qui d'une part maintient sans modification le fichier identitaire machin.plist & simultanément supprime machin du tableau Admin comme si l'identité machin avait cessé d'exister. Il s'agit manifestement d'une erreur de programmation faisant exister une contradiction dans un Système logique, càd. une inconsistance (ou incohérence).
----------
Un idéologue imbu du caractère sacré de l'État et appliquant indûment cette position politique au domaine de l'usage d'un Mac où le Système macOS devient un épitome de l'État de Droit, doit forcément ne pas "aimer" qu'on mette en évidence une contradiction logique à l'œuvre dans la régulation dudit Système. Comme si l'Amour Sacré de l'État empêchait l'entendement de constater une incohérence dans la régulation du Système.
Je sais bien qu'un avertissement dans le sous-panneau des Options avancées alerte l'utilisateur sur des risques éventuels liés à des modifications de paramètres de la carte d'identité d'utilisateur. Mais je signale à ceux qui soutiennent que la seule méthode légitime consiste à agir dans le sous-panneau des Options avancées d'un utilisateur machin à partir de la session Admin d'un autre utilisateur brol --> que le même avertissement s'affiche dans le panneau des Options avancées de machin. Ce qui fait que la situation de risque est a priori identique. Il n'y a donc aucun sens intrinsèque à valoriser exclusivement une manipulation indirecte sur une manipulation live. Sauf que - je le répète - une erreur de programmation dans les ressources de l'Open Directory de High Sierra seul donne lieu à une contradiction d'effets quand l'utilisateur tente de modifier en mode "live" son nom court. Je dis bien : "tente" --> puisqu'aucune modification effective du nom court n'est enregistrée. Et malgré cette non modification réelle > le daemon en service de l'Open Directory fait comme si une modification était intervenue en supprimant l'utilisateur du tableau Admin (sans le remplacer par une nouvelle identité d'utilisateur, puisque cette nouvelle identité n'as pas été enregistrée).
On ne peut pas culpabiliser des utilisateurs pour tenter de faire usage d'un droit que le Système leur accorde et qui ne produisait pas d'effets contradictoires dans la série des OS précédant High Sierra. Il convient de constater qu'il y a bien ici une faute logique de programmation du Système.
Dernière édition par un modérateur:
- Statut
Sujets similaires
10.12 Sierra
J'ai perdu mon statut Admin
10.13 High Sierra
Mot de passe administrateur ne fonctionne pas
10.13 High Sierra
Mon compte Administrateur est passé Standard