10.13 High Sierra compte administrateur passé en "Standard" par erreur

[Membre supprimé 1060554]

Tu est bien dans le terminal de la session du Single User quand tu passes la commande ?

 

[Khamsin]

Tu est bien dans le terminal de la session du Single User quand tu passes la commande ?

Oui, pour autant que je puisse en juger. A toutes fins utiles, voici une capture d'écran (artisanale):

 

[Membre supprimé 1060554]

Tu as fait une erreur à la commande précédente. Tu as accollé -uw/ alors qu'il faut détacher par un espace les options -uw et / (qui désigne le volume démarré en mode "mineur" par son point de montage).

Conséquence : n'ayant pas réussi à remonter le volume monté par défaut en lecture seule => en mode lecture & écriture --> la commande de suppression suivante n'a... rien supprimé.

Cette erreur est plutôt une bonne nouvelle --> elle veut dire que si tu repasses la commande :

mount -uw /

• de manière valide cette fois --> la commande de suppression va opérer ensuite.

 

[Membre supprimé 1060554]

Note : le message précédent m'a échappé au postage avant d'avoir été finalisé. Rafraîchis cette page pour le lire à l'état achevé.

 

[Khamsin]

Tu as fait une erreur à la commande précédente. Tu as accollé -uw/ alors qu'il faut détacher par un espace les options -uw et / (qui désigne le volume démarré en mode "mineur" par son point de montage).

Conséquence : n'ayant pas réussi à remonter le volume monté par défaut en lecture seule => en mode lecture & écriture --> la commande de suppression suivante n'a... rien supprimé.

Cette erreur est plutôt une bonne nouvelle --> elle veut dire que si tu repasses la commande :

mount -uw /

• de manière valide cette fois --> la commande de suppression va opérer ensuite.

Fantastique, ça a marché! Tu es le meilleur. Merci mille fois!

 

[Membre supprimé 1060554]

Content pour toi !

- note : je n'ai toujours pas compris d'où provient l'échec d'usage du Terminal dans la session de secours de certains Mac. Car l'OS de secours relève d'un volume monté en mode lecture seule : on voit mal alors ce qui pourrait corrompre quelque chose dans ce volume...​

 

[Khamsin]

Content pour toi !

- note : je n'ai toujours pas compris d'où provient l'échec d'usage du Terminal dans la session de secours de certains Mac. Car l'OS de secours relève d'un volume monté en mode lecture seule : on voit mal alors ce qui pourrait corrompre quelque chose dans ce volume...​

Honnêtement: aucune idée, mais ce qui est sûr, c'est qu'à force de vouloir tout verrouiller, Apple crée des problèmes insoupçonnés. En revanche, je ne comprends pas comment MacOS peut permettre la suppression du seul compte administrateur d'une machine sans au moins un message d'avertissement. Ils en mettent pour toutes sortes d'opérations avec moins de conséquences alors pourquoi pas ici?

 

[r e m y]

Honnêtement: aucune idée, mais ce qui est sûr, c'est qu'à force de vouloir tout verrouiller, Apple crée des problèmes insoupçonnés. En revanche, je ne comprends pas comment MacOS peut permettre la suppression du seul compte administrateur d'une machine sans au moins un message d'avertissement. Ils en mettent pour toutes sortes d'opérations avec moins de conséquences alors pourquoi pas ici?

Pour penser à afficher ce type de message d'alerte, encore faut-il que cette modification de statut soit identifiée par le système. Comme il s'agit d'une erreur de programmation, ce changement de statut s'opère à l'insu de l'OS (qui ne s'en rend donc même pas compte, d'où une incapacité à alerter sur les conséquences de la chose)

 

[Membre supprimé 1060554]

Le problème découle d'une erreur de programmation de l'Open Directory (Service d'Annuaire qui gère les utilisateurs et les groupes) > dans le seul OS High Sierra 10.13 -->

• dans cet OS exclusivement > tenter le modifier le nomcourt d'utilisateur en mode "live" (à partir de sa propre session ouverte) --> produit un double effet : a) le nomcourt n'est pas modifié (effet nul) > b) le statut du compte Admin est dégradé immédiatement à Standard

Dans les OS précédant High Sierra > la modification du nomcourt est supportée en mode "live" > et de nouveau dans l'OS Mojave 10.14. Absolument rien n'a été fait > d'une MÀJ à l'autre de High Sierra --> pour corriger cette erreur qui a causé d'innombrables victimes.

----------

Note : il y a 2 bases de données concernées par la modification du nomcourt d'utilisateur : un dossier users (/private/var/db/dslocal/ nodes/Default/users) contenant les fichiers identitaires d'utilisateurs et un fichier admin.plist contenu dans la base de données des groupes (/private/var/db/dslocal/nodes/Default/groups/admin.plist). Voici ce qui doit se passer quand l'utilisateur machin modifie son nomcourt à brol (par exemple) -->

• le fichier identitaire machin.plist doit être renommé brol.plist > et dans ce fichier > la clé intitulée name (nomcourt) doit prendre comme valeur brol à la place de machin

• dans le fichiers admin.plist qui comporte un tableau (array) contenant tous les nomscourts des utilisateurs faisant partie du groupe admin > le nom machin doit être supprimé > et il doit être remplacé par le nouveau nom brol

Il apparaît donc qu'une programmation complexe est impliquée. Dans High Sierra --> le fichier identitaire machin.plist n'est pas renommé brol.plist en mode "live" > la clé name reste associée à la valeur machin (et pas brol) > mais dans le fichiers admin.plist --> a) le nom machin est supprimé du tableau admin > mais il n'est pas remplacé par un nom brol. En rédumé : la seule action effectuée consiste à supprimer le nom machin dans le tableau admin du fichier admin.plist > mais nullement dans le fichier identitaire machin.plist.

 

[Khamsin]

Le problème découle d'une erreur de programmation de l'Open Directory (Service d'Annuaire qui gère les utilisateurs et les groupes) > dans le seul OS High Sierra 10.13 -->

• dans cet OS exclusivement > tenter le modifier le nomcourt d'utilisateur en mode "live" (à partir de sa propre session ouverte) --> produit un double effet : a) le nomcourt n'est pas modifié (effet nul) > b) le statut du compte Admin est dégradé immédiatement à Standard

Dans les OS précédant High Sierra > la modification du nomcourt est supportée en mode "live" > et de nouveau dans l'OS Mojave 10.14. Absolument rien n'a été fait > d'une MÀJ à l'autre de High Sierra --> pour corriger cette erreur qui a causé d'innombrables victimes.

----------

Note : il y a 2 bases de données concernées par la modification du nomcourt d'utilisateur : un dossier users (/private/var/db/dslocal/ nodes/Default/users) contenant les fichiers identitaires d'utilisateurs et un fichier admin.plist contenu dans la base de données des groupes (/private/var/db/dslocal/nodes/Default/groups/admin.plist). Voici ce qui doit se passer quand l'utilisateur machin modifie son nomcourt à brol (par exemple) -->

• le fichier identitaire machin.plist doit être renommé brol.plist > et dans ce fichier > la clé intitulée name (nomcourt) doit prendre comme valeur brol à la place de machin

• dans le fichiers admin.plist qui comporte un tableau (array) contenant tous les nomscourts des utilisateurs faisant partie du groupe admin > le nom machin doit être supprimé > et il doit être remplacé par le nouveau nom brol

Il apparaît donc qu'une programmation complexe est impliquée. Dans High Sierra --> le fichier identitaire machin.plist n'est pas renommé brol.plist en mode "live" > la clé name reste associée à la valeur machin (et pas brol) > mais dans le fichiers admin.plist --> a) le nom machin est supprimé du tableau admin > mais il n'est pas remplacé par un nom brol. En rédumé : la seule action effectuée consiste à supprimer le nom machin dans le tableau admin du fichier admin.plist > mais nullement dans le fichier identitaire machin.plist.

Merci pour ces explications. Je crois que je viens de comprendre comment j'ai perdu mon statut Admin. Après avoir déballé mon MBP, j'ai voulu le tester et j'ai créé un compte admin à mon nom. Ensuite, dans un deuxième temps, j'ai importé ma sauvegarde Time Machine de mon ancien Mac. Comme celle-ci avait le même nom d'utilisateur que le compte déjà créé, MacOS m'a forcé à créer un utilisateur avec un nom différent pour pouvoir faire l'importation. Je suis à peu près certain de lui avoir également attribué des droits admin. Une fois l'importation réussie, j'ai supprimé le compte à mon nom (vide) et n'ai gardé que celui avec le nom fantaisiste, auquel sont liées toutes mes données. Et là, j'ai tenté l'opération fatidique de vouloir remplacer le nom fantaisiste par mon vrai nom, ce qui n'a non seulement pas marché mais engendré le problème de suppression des droits admin...

 

[Moonwalker]

Encore une fois, et en totale opposition avec Macomaniac, ce n’est pas un bug de programmation de quoique ce soit. En suivant des procédures incomplètes, ou en les parcourant à la va-vite, vous oubliez à chaque fois l’étape essentielle dans le changement de nom de compte, à savoir modifier le nom du dossier départ et son chemin, opération impossible si on est sur la même session que le nom de compte à modifier, opération qui nécessite obligatoirement de procéder à partir d’un autre compte administrateur (quelque soit l’OS).

Avec Sierra et avant : le système faisait comme si de rien n’était mais l’erreur demeurait en attente de se manifester.
Avec High Sierra : l’erreur se paie cash.

Voilà tout.

La question est réglée avec Mojave : le nom de compte est maintenant verrouillé comme le nom du dossier de départ. Vous devez OBLIGATOIREMENT procéder depuis un autre compte administrateur pour tout changement.

j'ai importé ma sauvegarde Time Machine de mon ancien Mac. Comme celle-ci avait le même nom d'utilisateur que le compte déjà créé, MacOS m'a forcé à créer un utilisateur avec un nom différent pour pouvoir faire l'importation.

Je présume que vous n’avez pas procédé depuis /Utilitaires/Assistant Migration ou que votre compte source avait un autre UID que 501.

 

[Fullcrum]

La procédure de macomaniac est parfaitement rodée en tout points !

Par contre depuis Mojave ( Moravé ) effectivement le nom de départ est verrouillé, car j'ai changé le " nom complet " y'a fort longtemps sur mon 15" pour avoir mon pseudo " Fulcrum " en lieu est place de nom prénom à l'affichage sur les différentes page où celui-ci était mentionné. C'est toujours le cas sauf dans le Mac App Store où mon nom et prénom affiche en bas à gauche. C'est pas bien grave.

Donc j'ai changé: le nom complet et même ma fiche contact passant de Moi à Admin, cela fait un bail que c'est comme ça et je ne rencontre aucun souci.

 

[Moonwalker]

car j'ai changé le " nom complet "

Le nom complet n’a jamais posé de problème. C’est le nom du compte (aka nom abrégé) qui est en cause. Faut suivre. :meh:

Le nom de compte est toujours modifiable avec Mojave, à partir d’une session administrateur, en n’oubliant pas modifier d’abord le nom du dossier de départ et ensuite le chemin qui conduit à celui-ci. Sinon : surprise !

 

[Membre supprimé 1060554]

avec Mojave : le nom de compte est maintenant verrouillé comme le nom du dossier de départ.

- je m'inscris en faux, expérimentalement parlant. Dans Mojave > j'ai très bien pu déverrouiller le cadenas des Préférences Système > sélectionner mon nom d'utilisateur macomaniac la touche ctrl pressée > accéder aux Options avancées > et modifier à la main mon Nom du compte macomaniac en maco. Aucune dégradation du compte de Admin à Standard. J'ai redémarré > me suis logé dans ma session sans problème > et mon Nom du compte est bien maco. J'ai répété cette manipulation aussi bien le SIP désactivé qu'activé.​

• cette possibilité de modification du Nom de compte en mode "live" (depuis la session ouverte de l'utilisateur concerné) > effective sans dommage collatéral dans tous les OS précédant High Sierra (comme de patientes expérimentations de ma part l'ont avéré) > se trouve récupérée dans l'OS Mojave. En fait foi mon expérimentation encore.

vous oubliez à chaque fois l’étape essentielle dans le changement de nom de compte, à savoir modifier le nom du dossier départ et son chemin

• opération qui apporte une cohérence nominale (identité du Nom du compte et du nom du dossier domicile) > mais qui n'a aucune nécessité logique. Dans mon exemple ci-dessus > je n'ai pas modifié le nom du dossier domicile macomaniac > le chemin d'ouverture de session est bien demeuré : /Users/macomaniac --> ce qui n'a empêché en rien maco d'ouvrir sa session dessus. Il faudrait bien plutôt admirer l'opération (prise en charge par le service opendirectoryd) qui fait que le nouvel utilisateur à Nom de compte maco --> se trouve rendu propriétaire du dossier macomaniac et de tous ses contenus --> ce qui fait qu'aucun problème de permissions n'intervient.

En résumé : Il faudrait désormais arrêter de soutenir des assertions qui s'adressent en priorité à l'entendement des autres (visée idéologique) > sans avoir la confirmation préalable de l'expérience (vérité logique). Càd. il faudrait faire passer la vérité logique avant les préférences idéologiques.

 

[r e m y]

Moonwalker démontre une nouvelle fois qu'il n'a pas encore compris comment fonctionne le Service d'annuaire...
Le nom et le chemin du dossier de départ étant l'un des paramètres enregistrés pour un utilisateur donné, rien n'interdit qu'il ne porte pas le même nom que le nom court du dit utilisateur !

 

[Moonwalker]

- je m'inscris en faux, expérimentalement parlant. Dans Mojave > j'ai très bien pu déverrouiller le cadenas des Préférences Système > sélectionner mon nom d'utilisateur macomaniac la touche ctrl pressée > accéder aux Options avancées > et modifier à la main mon Nom du compte macomaniac en maco. Aucune dégradation du compte de Admin à Standard. J'ai redémarré > me suis logé dans ma session sans problème > et mon Nom du compte est bien maco. J'ai répété cette manipulation aussi bien le SIP désactivé qu'activé.

Avec macOS 10.4.1 Mojave le nom de compte est verrouillé sur la session (admin ou pas) active. Expérimenté aussi. Pas plus tard qu’au moment de mon post.

Le nom du compte est verrouillé, grisé, non modifiable. C’est un fait ! :meh:

opération qui apporte une cohérence nominale (identité du Nom du compte et du nom du dossier domicile) > mais qui n'a aucune nécessité logique. Dans mon exemple ci-dessus > je n'ai pas modifié le nom du dossier domicile macomaniac > le chemin d'ouverture de session est bien demeuré : /Users/macomaniac --> ce qui n'a empêché en rien maco d'ouvrir sa session dessus. Il faudrait bien plutôt admirer l'opération (prise en charge par le service opendirectoryd) qui fait que le nouvel utilisateur à Nom de compte maco --> se trouve rendu propriétaire du dossier macomaniac et de tous ses contenus --> ce qui fait qu'aucun problème de permissions n'intervient.

Interprétation qui n’a d’autre origine que ton esprit étriqué. Ça me rappelle jadis ton délire sur Rosetta à partir des caches de chargement dynamiques. :hilarious:

Ton « aucune nécessité logique » est pourtant un impératif rappelé par Apple dans sa documentation. :rolleyes:

« Le nom du compte (nom abrégé) permet de créer le dossier de départ d’un utilisateur, c’est pourquoi le nom du compte et celui du dossier de départ doivent être identiques. »

https://support.apple.com/fr-fr/HT201548

1. Déconnectez-vous du compte que vous souhaitez renommer, puis connectez-vous à un compte d’administrateur.
   Le compte d’administrateur doit être différent de celui que vous renommez. Si nécessaire, créez un nouveau compte d’administrateur, puis supprimez-le lorsque vous avez terminé cette procédure.
2. Accédez au dossier Utilisateurs, se trouvant sur le disque de démarrage. Ce dossier comprend le répertoire de départ du compte que vous souhaitez renommer. Modifiez le nom du répertoire, et prenez note du nouveau nom, comme de l’ancien. Lorsque vous renommez un dossier, vous êtes invité à saisir le nom et le mot de passe d’administrateur que vous avez utilisés pour vous connecter.
3. (…)
4. (…)
5. (…)
6. Dans le champ « Nom du compte », saisissez le nom que vous avez attribué au dossier de départ du dossier Utilisateurs.
7. Dans le champ « Répertoire de départ », saisissez le nom que vous avez attribué au dossier de départ dans le dossier Utilisateurs.

Toute la documentation Apple insiste sur la cohérence nécessaire entre le dossier de départ et le nom abrégé. Mais puisque Macomaniac prétend le contraire… c’est sûr qu’il connait mieux macOS que ceux qui l’ont conçu.

En résumé : Il faudrait désormais arrêter de soutenir des assertions qui s'adressent en priorité à l'entendement des autres (visée idéologique) > sans avoir la confirmation préalable de l'expérience (vérité logique). Càd. il faudrait faire passer la vérité logique avant les préférences idéologiques.

Il n’y a que toi pour comprendre ce que tu veux dire par là. « Préférences idéologiques » ?!! T’es bien dans ta tête ? o_O

Aucune idéologie. Des faits démontrés pour ma part.

 

[Moonwalker]

Moonwalker démontre une nouvelle fois qu'il n'a pas encore compris comment fonctionne le Service d'annuaire...
Le nom et le chemin du dossier de départ étant l'un des paramètres enregistrés pour un utilisateur donné, rien n'interdit qu'il ne porte pas le même nom que le nom court du dit utilisateur !

Remy démontre qu’il ferait mieux de rester en dehors des discussions qui le dépassent.

 

[Membre supprimé 1060554]

L'utilisateur admin aborigène (UID : 501) --> n'a pas la case du Nom de compte grisée : il peut donc parfaitement dans Mojave effectuer en mode "live" un changement de ce nom.

Ce sont les utilisateurs admin épigones (UID : 504 par exemple comme le nommé jeanbon) --> qui ont une case du Nom de compte grisée : ils sont donc obligés dans Mojave de passer par un autre administrateur.

J'ai donc utilisé dans Mojave une possibilité accordée à l'admin 501 de modifier son Nom de compte en mode "live" --> cette opération réussit parfaitement sans dégradation du statut du compte à Standard.

Elle réussit également sans changement du nom du dossier de compte (qui demeure identique). Car l'intitulé du dossier n'a aucune importance : ce qui importe > ce sont les permissions sur ce dossier et ses contenus. L'utilisateur macomaniac peut ouvrir sa session sur un dossier de compte intitulé jeanbon - cela ne pose aucun problème --> il faut et il suffit que macomaniac soit l'user = le propriétaire en lecture / écriture > exécution du dossier jeanbon et des ses contenus. Cette modification des permissions sur le dossier de compte en relation avec le changement du Nom de compte --> est assurée par le service opendirectoryd sans que l'utilisateur intervienne.

Il ne faut donc pas confondre l'intitulé d'un objet et les permissions affectées à cet objet. macomaniac peut être l'user d'un dossier intitulé brol ou machin et pas seulement d'un objet intitulé identiquement macomaniac. De ce point de vue > le dossier domicile sur lequel l'utilisateur ouvre sa session n'a pas de privilège par rapport à un simple de dossier de stockage de données : ce qui importe seul concernant l'accès au dossier > c'est que macomaniac soit l'user en rwx (read write execute) de ce dossier.

Il ne faut donc pas confondre une préconisation d'homogénéité nominale (l'utilisateur macomaniac a un dossier domicile intitulé aussi macomaniac) > parce qu'elle rend les choses plus évidentes en pratique / avec une nécessité logique complètement absente - les seules permissions sur un objet d'un nom quelconque suffisant à en faire la propriété d'un utilisateur.

Dans l'OS High Sierra > si l'utilisateur admin 501 tente l'opération de modification "live" du Nom du compte > alors : a) cette tentative est avortée (aucun changement ne se trouve enregistré) > mais b) cette simple tentative avortée suffit à dégrader son statut de compte de Admin à Standard. Qu'une action à effet nul en ce qui concerne son objet (renommer) > ait un effet collatéral non nul (dégrader le statut du compte) : c'est manifestement l'effet d'une erreur de programmation. Ce qui n'intervient plus dans Mojave > où tout utilisateur 501 pourra modifier son nom court en mode "live".

On ne devrait plus avoir de plaignants d'une perte de statut admin dans Mojave > si l'on assume que les utilisateurs qui changent leur Nom de compte ont sur une base régulière l'UID 501.

 

[Khamsin]

Oula, je m'en veux d'avoir déclenché une "guerre de religion". En tout cas, je confirme qu'en tant qu'utilisateur lambda, je suis plus intéressé par le résultat pratique que par l'orthodoxie de la méthode employée. Je soumets donc à tes lumières un nouveau "problème" (bien moins grave que le précédent): j'ai voulu tester ta méthode et renommer mon compte en live après avoir installé Mojave dans la nuit. Il s'avère qu'il a l'UID 502, ce qui semble logique, puisque je l'avais créé dans un deuxième temps, au moment de l'importation de mes données TimeMachine (cf. post précédent). J'ai donc tenté de créer un nouveau compte admin avec mon vrai nom et celui-ci s'est vu attribuer l'UID 501. Voici mes questions: 1) Est-il important que mon compte principal (celui avec mes données) ait l'UID 501 ou est-ce que cela n'a guère d'implications pratiques? 2) S'il est important qu'il ait l'UID 501, comment faire pour que l'UID 501 ait accès à mes données et réglages? 3) Si je peux continuer à vivre avec l'UID 502 sans inconvénients pratiques, quel est le moyen le plus sûr pour renommer ce compte sans faire de dégâts?

 

[Moonwalker]

T’as rien déclenché. C’est une divergence d’interprétation qui courre entre nous deux depuis un certain temps sur ce qui se passe avec High Sierra.


@macomaniac

Je reviens te répondre dans quelques minutes. Attention à la surprise !