Qui est "Wheel" sous Mavericks

[Ibiscus]

Bonsoir,

En voulant faire un test sur le SSD système de mon Mac Pro avec BlackMagic Disc Speed Test, ce que je n'avais pas, semble-t-il, fait depuis que j'ai installé Mavericks, j'ai eu un refus " le disque n'est qu'en lecture" !
Je regarde Info sur le SSD et je trouve :
Système ==> Lecture et écriture
Wheel ==> Lecture seulement
everyone ==> Lecture seulement

je suis étonné car je n'ai jamais vu indiqué "Wheel" auparavant. Je n'arrive d'ailleurs pas à trouver une traduction plausible de ce mot anglais. Mais je suis surpris de ne pas trouver pour le moins "admin" ou "xxx(moi)"
J'ai rajouté "admin" avec "Lecture et écriture" et j'ai pu faire le test de vitesse.

Les questions que je me pose :
- est-ce que je prends un risque en laissant en permanence "admin" ?
- est-ce que tout cela est normal avec Mavericks ?
- que représente "Wheel" ?

Merci de vos conseils

Précisions : Le SSD est sur une carte CPIe/SATA III Apricorn, je n'ai pas constaté de problème avec Mavericks sauf avec le logiciel DOO (je n'en saurais pas plus car le SAV m'a appris que les dévellopeurs arrêtent purement et simplement DOO).

 

[gmaa]

Bonsoir,

Un peu de lecture...
: : OS X facile : : Les permissions

http://www.osxfacile.com/arborescence.html

Attention "terrain glissant"!
On a vite fait de...

 

[Moonwalker]

Un peu plus fouillé : Les Droits et Autorisations Mac OS X (1)

That's the question : osx - What is the "wheel" user in OS X? - Super User

 

[Membre supprimé 1060554]

Salut Ibiscus.

wheel ('rouage') est le groupe d'appartenance exclusive de root (le Super-Administrateur_Système). Ne comprenant que ce seul membre, c'est donc un 'Super_Groupe'. Les droits sur l'espace-racine :

drwxr-xr-x  root  wheel

sont absolument réguliers et légitimes ('d' = 'directory' comme 'espace de répertoire global' ; 'rwx' = 'read' + 'write' + 'execute' comme lecture/écriture/exécution pour root ; 'r-x' = 'read' + 0 + 'execute' comme lecture/0/exécution pour wheel <pas de droits d'édition pour le groupe> ; 'r-x' = 'read' + 0 + 'execute' comme lecture/0/exécution pour other <pas de droits d'édition pour le tout-venant>).

En rajoutant le groupe admin (dont tu es membre) en co-groupement de wheel sur le répertoire racine de l'OS, tu as créé une ACE (access control entry), archivée dans la liste d'ACL (access control list) qui crée une bréche de sécurité sur l'espace immédiatement adjacent au point de montage logiciel de l'OS. Si jamais (en utilisant, je le présume, une fenêtre d'information du Finder pour ce faire), tu as utilisé le bouton inférieur ('engrenage') pour actionner l'option : 'Étendre aux éléments inclus', tu as étendu récursivement l'ACL précédente à tous les sous-étages de répertoires et de fichiers de l'architecture de l'OS : il ne s'agit plus d'une brèche de sécurité liminaire, il s'agit alors d'une série de portes ouvertes à tous les niveaux qui affecte gravement l'organisation des droits de l'OS. Si jamais tu lances l'«Utilitaire de Disque» en lui demandant la vérification/réparation des autorisations - je gage que l'issue ne va pas être triste.

Si tu t'es contenté, dans une fenêtre d'info du Finder, de créer une ACE sur l'espace-racine, il t'est facile de la résilier par la même méthode, en supprimant le groupe admin de la co-propriété avec le groupe wheel sur le répertoire global de l'OS. Si tu as étendu récursivement cette ACE à tous les sub-étages de l'architecture de l'OS, c'est fichu : tu ne peux pas faire machine arrière, par exemple, une fois restauré wheel en unique groupe, en étendant récursivement cette propriété de groupe à tous les sous-étages de l'OS, car il y a des répertoires système (comme celui des 'Applications') qui demandent comme groupe admin et pas wheel pour être gérés, ce que l'action récursive abolirait. La seule récupération de droits valable à tous les échelons de l'OS passe par la ré-installation du système en mode : 'mise-à-niveau'.

[Un logiciel digne de ce nom n'a pas a requérir la création d'une ACE pour intervenir à un niveau système. Il lui suffit de requérir une authentification admin de la part de son initiateur, ce qui lui permet d'être investi de droits root le temps d'une opération.]

 

[Ibiscus]

Merci gmaa, mais je connaissais déjà ces infos qui s'appliquent aux fichiers dans les exemples.

Merci Moonwalker, j'ai pu compléter mes connaissances, et en particulier sur Wheel :
big wheel
noun Informal.
an influential or important person: a big wheel in business.
Origin:
1905–10
Cela a l'odeur de l'humour des informaticiens

Et un grand merci à macomaniac pour sa longue et intéressante communication, même si j'ai pas tout compris à la première lecture...
Oui, j'ai ajouté "admin" avec privilège "Lecture et écriture" dans "Partage et permissions" par "+" après avoir déverrouillé le cadenas après avoir fait cmd-i sur l'icône du SSD et avoir ouvert les infos.
D'après ce que tu écris, heureusement que je n'ai pas touché à la roue dentée
Je peux donc revenir en arrière en faisant "-" sur "admin" sans dégât, c'est bien cela ?

 

[Membre supprimé 1060554]

Je peux donc revenir en arrière en faisant "-" sur "admin" sans dégât, c'est bien cela ?

&#9757;&#65038; La réponse eeeeeest : OUI

&#9828;​

NB. Quand tu veux qu'une application s'exécute sans limitations de droits, tu la lances avec des droits root ('root' = le nom propre du 'Super-Administrateur_Système', càd. la personnification de ce qui apparaît comme 'Système' dans les fenêtres d'info du Finder). Pour cela, il faut que tu repères le binaire = le programme exécutable qu'elle recèle (car l'icône apparemment pleine et sollde d'une application n'est qu'une apparence esthétique, qui camoufle un bundle : un paquetage où il y a des valises dans une malle, des chemises dans les valises et des marcels fichiers dans les chemises - où est-ce que j'en suis, déjà?). Donc, il faut aller à la bonne adresse (et Apple est pire qu'une mère de famille nombreuse pour les vêtements de ses rejetons : elle exige que dans les 'commodes' des applications, tout soit méticuleusement rangé dans des tiroirs correspondants portant chaque fois les mêmes étiquettes ). Prends «iTunes» : tu fais un clic_secondaire (clic droit) sur l'icône et tu choisis dans la fenêtre surgissante : 'Afficher le contenu du paquet'. À partir de là, navigues en suivant le chemin suivant : Contents/MacOS/ et tu as le binaire qui porte régulièrement l'intitulé de l'application. Ici, il y a foule (ce qui est rare) : le binaire est donc iTunes. Tu laisses cette fenêtre Finder ouverte, et tu t'arranges pour lancer le «Terminal» (/Applications/Utilitaires) en parallèle. Dans la fenêtre qui s'ouvre, tu contemples ton nom_abrégé d'utilisateur (qu'on supposera ibiscus) suivi du sigle '$', càd. :

ibiscus$

C'est ce qu'on appelle le 'prompt' (= 'invite de commande'). Un pointeur jouxte ce 'prompt', comme dans un traitement de texte. Tu tapes directement à cet emplacement par défaut:

sudo

et tu crées une espace en appuyant une fois sur la barre d'espacement. Cela fait, tu fais carrément un glisser-déposer du binaire (iTunes dans l'exemple que j'ai choisi) dans la fenêtre du «Terminal». Je te rassure : ce procédé graphique ne touche absolument pas le fichier exécutable de l'application, il se contente de renseigner automatiquement par écrit le chemin au binaire ainsi que sa désignation. Ainsi, ici tu obtiens automatiquement :

sudo /Applications/iTunes.app/Contents/MacOS/iTunes

et tu fais &#8617;&#65038; (retour-chariot : tu presses la touche 'Entrée' = 'Retour' du clavier pour activer la commande). Comme tu as préfixé le binaire de 'sudo' (substitute_user_do = exécuter en qualité d'utilisateur substitut provisoire -5'- de root, càd. en tant que sudoer), tu dois montrer patte blanche pour obtenir l'autorisation d'endosser la cape de sudoer. Ce qui t'est demandé par l'affichage de 'password'. Tu tapes à l'aveugle (aucun caractère ne se montrant à la frappe) ton mot-de-passe admin [seul un membre du groupe admin a le droit de se promouvoir sudoer, et il le prouve en renseignant son mot-de-passe admin] et derechef tu fais &#8617;&#65038;. Ton application va se lancer en droits root sans avoir besoin que tu crées une ACE sur l'espace-racine. Mais attention : le procédé requiert que tu laisses la commande active dans le «Terminal» tout le temps de l'usage de l'application, càd. que tu ne quittes pas ledit «Terminal».

Quelle que soit l'application que tu veuilles faire s'exécuter en droits root (il est rare que ce soit intéressant et comme tu vois c'est un peu malcommode), le procédé constant consiste à renseigner dans le «Terminal», après l'invocation sudo et une espace libre, le chemin_au_binaire_de_l'application, qui est constamment à l'adresse :

/Applications/nom_de_l'application.app/Contents/MacOS/nom_du_binaire

&#9831;​

 

[bompi]

Je m'autorise une petite rectification (de mémoire, n'ayant malheureusement pas de Mac OS X récent sous la main).
wheel n'est pas le groupe du seul root : tout compte considéré comme administrateur de l'ordinateur est inséré dans le groupe wheel. Tout aussi bien, tout compte qui n'est plus considéré comme administrateur est retiré du groupe wheel.

root, c'est le super-utilisateur, le big boss de l'ordinateur, celui qui peut tout faire. Par mesure de sécurité, ce compte, quoiqu'actif, n'est pas directement utilisable. On confère à d'autre comptes (notamment le premier compte utilisateur créé sur la machine) le droit de devenir l'équivalent de root lorsqu'une tâche administrative se présente : définir un disque Time Machine, créer une nouvelle interface réseau, installer une application pour tout le monde, installer une mise à jour du système etc.

La méthode, très simple, de conférer ce droit à un utilisateur, c'est de l'ajouter au groupe wheel. C'est ce qui est fait lorsqu'on coche la case donnant les droits d'administration à un utilisateur, dans les Préférences Systèmes.

 

[FrançoisMacG]

Je m'autorise une petite rectification (de mémoire, n'ayant malheureusement pas de Mac OS X récent sous la main).
wheel n'est pas le groupe du seul root : tout compte considéré comme administrateur de l'ordinateur est inséré dans le groupe wheel. Tout aussi bien, tout compte qui n'est plus considéré comme administrateur est retiré du groupe wheel.

Dans mon Terminal 10.8, sudo dscl . -read /Groups/wheel GroupMembership me répond : root

= tu confonds avec admin.

 

[Ibiscus]

Merci macimaniac, je suis revenu en arrière sans encombre semble-t-il.

Sur un DD de mon Mac Pro j'ai Snow Leopard d'installé avec :
Système ==> Lecture et écriture
admin ==> Lecture et écriture
everyone ==> lecture seulement

alors que sur le SSD avec Mavericks
Système ==> Lecture et écriture
Wheel ==> Lecture seulement
everyone ==> Lecture seulement

Or j'arrive bien à installer des logiciels et plein d'autres choses en tant qu'administrateur. J'ai l'impression d'Apple a durci les conditions d'accès. Hypothèse l'administrateur s'adresse maintenant au système qui exécute si cela lui convient ?

 

[bompi]

Dans mon Terminal 10.8, sudo dscl . -read /Groups/wheel GroupMembership me répond : root

= tu confonds avec admin.

Pas vraiment. En fait, wheel a été utilisé pendant quelques versions de Mac OS X (comme sur d'autres moutures de UNIX) puis Apple est passé à admin (ce qui a d'ailleurs créé quelques soucis lors de transitions vers de nouveaux systèmes par mise à jour (certaines fonctionnalités devenaient un peu bancales)).

Les principes sous-tendant cette organisation des comptes restant exactement les mêmes.

 

[FrançoisMacG]

Juste à titre historique :

admin a été le groupe de Macintosh HD jusque 10.5,
et c'est en clean install de 10.6 que wheel l'a remplacé (les mises à niveau gardaient admin).


Mon 10.8 (upgradé depuis Lion) tourne avec admin (je l'ai remis un jour, pour une mauvaise raison, et je l'ai laissé).
Et mon 10.6 l'a conservé après l'upgrade depuis 10.5.
Mais je n'utilise pas BlackMagic Disc Speed Test.

 

[bompi]

Donc finalement, c'était plutôt le premier post le bon ?
Je re-vérifierai ce soir (SL, ML et Micks disponibles ).

 

[Membre supprimé 1060554]

Sur mon «Snow Léopard Server 10.6.8» (non bidouillé), voici les droits radicaux (j'ai éliminé pour la clarté les dossiers invisibles de type .Trashes, .dropbox etc.) :

drwxrwxr-t@               root            [COLOR="RoyalBlue"]admin[/COLOR]      .
drwxrwxr-t@               root            [COLOR="RoyalBlue"]admin[/COLOR]      ..

drwxrwxr-x+               root            [COLOR="RoyalBlue"]admin[/COLOR]      Applications
drwxrwxr-x                root            [COLOR="RoyalBlue"]admin[/COLOR]      Developer
drwxrwxr-t+               root            [COLOR="RoyalBlue"]admin[/COLOR]      Groups
drwxrwxr-t+               root            [COLOR="RoyalBlue"]admin[/COLOR]      Library
drwxr-xr-x+               root            [COLOR="RoyalBlue"]admin[/COLOR]      Users
drwxrwxrwt@               root            [COLOR="RoyalBlue"]admin[/COLOR]      Volumes
drwxrwxr-t@               root            [COLOR="RoyalBlue"]admin[/COLOR]      cores

drwxr-xr-x@               root            [COLOR="Teal"]wheel[/COLOR]      Network
drwxr-xr-x                root            [COLOR="Teal"]wheel[/COLOR]      Shared Items
drwxr-xr-x                root            [COLOR="Teal"]wheel[/COLOR]      System
rwxr-xr-x@                root            [COLOR="Teal"]wheel[/COLOR]      bin
dr-xr-xr-x                root            [COLOR="Teal"]wheel[/COLOR]      dev
lrwxr-xr-x@               root            [COLOR="Teal"]wheel[/COLOR]      etc -> private/etc
dr-xr-xr-x                root            [COLOR="Teal"]wheel[/COLOR]      home
-rw-r--r--@               root            [COLOR="Teal"]wheel[/COLOR]      mach_kernel
dr-xr-xr-x                root            [COLOR="Teal"]wheel[/COLOR]      net
drwxr-xr-x@               root            [COLOR="Teal"]wheel[/COLOR]      private
drwxr-xr-x@               root            [COLOR="Teal"]wheel[/COLOR]      sbin
lrwxr-xr-x@               root            [COLOR="Teal"]wheel[/COLOR]      tmp -> private/tmp
drwxr-xr-x@               root            [COLOR="Teal"]wheel[/COLOR]      usr
lrwxr-xr-x@               root            [COLOR="Teal"]wheel[/COLOR]      var -> private/var

Sous «Mavericks 10.9.1», admin est remplacé par wheel dans toutes les occurrences 'radicales' où le premier était le groupe accédant, à l'unique exception du répertoire : /Applications dont le groupe accédant reste admin.

Je note une série de curiosités : l'espace-racine, groups, library, volumes et cores portent le 'sticky_bit' ('brin gluant') en final des permissions sous «Snow Léopard », précaution entièrement abandonnée sous «Mavericks».

 

[Membre supprimé 1060554]

Mettons en regard du tableau précédent des droits 'radicaux' sous «Snow Léopard» celui des mêmes droits sous «Mavericks» (pareillement légèrement abrégé de certains dossiers invisibles) :

drwxr-xr-x@               root            [COLOR="Teal"] wheel[/COLOR]      .
drwxr-xr-x@               root            [COLOR="Teal"] wheel[/COLOR]      ..

drwxrwxr-x@               root             [COLOR="RoyalBlue"]admin[/COLOR]      Applications

[S]drwxrwxr-x                root            [COLOR="Teal"] wheel[/COLOR]      Developer[/S]
drwxr-xr-x@               root            [COLOR="Teal"] wheel[/COLOR]      Groups
drwxr-xr-x@               root            [COLOR="Teal"] wheel[/COLOR]      Library
drwxr-xr-x@               root            [COLOR="Teal"] wheel[/COLOR]      Users
drwxrwxrwt@               root            [COLOR="Teal"] wheel[/COLOR]      Volumes
drwxrwxr-t@               root            [COLOR="Teal"] wheel[/COLOR]      cores

drwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      Network
drwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      Shared Items
drwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      System
drwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      bin
dr-xr-xr-x                root             [COLOR="Teal"]wheel[/COLOR]      dev
lrwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      etc -> private/etc
dr-xr-xr-x                root             [COLOR="Teal"]wheel[/COLOR]      home
-rwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      mach_kernel
dr-xr-xr-x                root             [COLOR="Teal"]wheel[/COLOR]      net
drwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      private
drwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      sbin
lrwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      tmp -> private/tmp
drwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      usr
lrwxr-xr-x@               root             [COLOR="Teal"]wheel[/COLOR]      var -> private/var


[COLOR="Red"]drwxr-xr-x@               root             wheel      Documents
drwxr-xr-x@               root             wheel      Downloads

drwxrwxr-x@               root             admin      Incompatible Software

-rwxr-xr-x@               user             wheel      Guides de l’utilisateur
drwxr-xr-x@               user             admin      Desktop Folder
drwxr-xr-x@               user             admin      Dossier Transfert de fichiers??
[/COLOR]

Je remarque que sur les répertoires : Groups et Library, indépendamment du remplacement du groupe admin par wheel, les permissions d'écriture ('w') pour le groupe qui étaient accordées sous «Snow Léopard», sont sucrées sous «Mavericks».

Par ailleurs, curieusement, le fichier-core : mach_kernel ne portait pas de permissions d'exécution ('x') sous «Snow Léopard», comme si ce n'était pas un fichier exécutable, alors que sous «Mavericks» il a bien le statut de binaire avec permissions d'exécution.

Si le dossier 'Developer' (qui contenait Xcode sous «Snow Léopard») est bien supprimé, parce que, sous «Mavericks», Xcode est inclus désormais dans le répertoire des 'Applications' pour ceux qui l'installent ; je note l'ajout sous «Mavericks» de nouveaux répertoires 'radicaux' inconnus sous «Snow Léopard» : 'Documents', 'Downloads' associés au groupe wheel ; 'Incompatible Software' au groupe admin ; et 'Guides de l&#8217;utilisateur', 'Desktop Folder' et 'Dossier Transfert de fichiers?? exceptionnellement propriété de l'user en lieu de root, tandis que le groupe est admin pour les deux derniers.

&#9758; il me semble que la doctrine d'Apple concernant les droits (accédants et permissions) n'ait pas été fixée une fois pour toutes sous OSX en ce qui concerne les répertoires 'radicaux' (à la différence - toujours à ce qu'il me paraît - de l'architectonique du Système, remarquablement stable à travers le temps à partir du paradigme de «Tiger 10.4»).

Si l'on admet à ce jour 3 catégories d'OSX : PPC = de Cheetah 10.0 à Tiger 10.4 ; Transition PPC --> Intel = de Tiger 10.4_Intel, par Léopard 10.5, à Snow Léopard 10.6 -pur Intel mais émulant le code PPC ; INTEL_exclusif = de Lion 10.7, par Mountain Lion 10.8, à Mavericks 10.9 - j'ai l'impression d'un tour de vis sur les droits pour la dernière catégorie d'OSX.

&#9831;​

 

[phelibre]

A ce sujet, j'ai remarqué que les ID des users ne sont pas dans /etc/passwd comme pour un système Unix et il n'y a pas de fichier /etc/group !!!
Ou sont défini les groupes et les utilisateurs ?
Merci,

 

[Membre supprimé 1060554]

Salut phelibre

Dans le dossier : /private/var/db/dslocal/nodes/Default, sont localisés les sous-dossiers Groups & Users qui contiennent tous les .plist des groupes et des utilisateurs.

[Attention ! Sensible ! Default porte un sens interdit en navigation graphique : c'est le répertoire d'Annuaire].

 

[bompi]

Je pense que le mieux est de n'accéder à l'annuaire qu'en usant des applications et commandes qui lui sont dédiées.
Dans Terminal, c'est dscl.