Salut
mikeroy.
En mode "redondance" de la remarque
a) de
bompi : lorsqu'on utilise le service
ad hoc de l'«
Utilitaire d'Annuaire» relatif à l'utilisateur
root, il faut bien comprendre qu'on n'active pas root en tant qu'utilisateur de processus qui se lancent dès le démarrage de l'OS, parce que root sous ce rapport est toujours automatiquement "en charge" en tant qu'opérateur logique et qu'il serait absurde d'envisager une situation où il ne serait pas "actif" en tant qu'autorité responsable de processus-racine.
Non, ce qu'on active, c'est seulement la fonction d'usager graphique de root : sa capacité d'être un utilisateur de session graphique, comme le sont les utilisateurs standard et admin de l'OS. Pour cela, exactement comme pour ces derniers utilisateurs, la base de données du Service d'Annuaire des utilisateurs est éditée, avec création d'un "utilisateur graphique root" doté de paramètres ad hoc (identifiant d'utilisateur = 0, groupe de référence = wheel, nom du compte = root, nom complet = System Administrator, shell d'accès = /bin/bash, répertoire de départ = /private/var/root, UUID = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, mot de passe = ●●●●●) --> suite à ce paramétrage d'une identité d'utilisateur graphique de root dans le Répertoire d'Annuaire, il devient possible à l'utilisateur admin qui a activé cet "avatar" d'ouvrir une session graphique en qualité de root.
À la première ouverture de session, un Home_Directory (dossier de départ) au nom de root se trouve créé à l'adresse attendue : /private/var/root avec l'arborescence de sous-dossiers classique et la session s'ouvre dans l'environnement d'un Bureau géré par le Finder. Rien ne distingue une session graphique root d'une session d'utilisateur admin, sauf qu'en mode graphique l'utilisateur root ne connaît pas de "sens interdits", puisqu'il est l'avatar graphique de l'utilisateur souverain root en charge dès le déploiement de l'OS. Mais, comme remarqué par bompi, c'est uniquement si l'on ouvre une session root que cet utilisateur graphique agit en mode graphique. Si l'on n'ouvre pas de session graphique root, cet "avatar" n'est pas actuellement actif en tant qu'utilisateur graphique - seul opère le root logique en charge des processus-racine.
--> il faudrait donc, si tu veux manipuler en mode graphique sans "sens interdits" tel ou tel répertoire exclusivement propriété, avec ses sous-éléments, d'un utilisateur admin qui n'est pas toi-même, te loger chaque fois dans la session root afin d'agir en qualité de cet avatar graphique - sinon, aussi longtemps que c'est toi, logé dans ta session admin, qui monopolise la fonction d'utilisateur graphique, la session root étant fermée l'utilisateur graphique root dort sur ses deux oreilles.
♤
L'option hériter la sécurité au dossier actuelle et ses sous dossier (enfant) ne semble pas être diponible sur mac. Est-ce que je me trompe?
Oui, tu te trompes (si tu me permets cette assertion abrupte). Ce que tu appelles "sécurité", ce sont les droits (qui incluent le triplet des accédants à un objet : user-group-other ; et les triplets des permissions propres à chaque accédant relativement à cet objet : read-write-execute présentes/absentes selon les cas). Ce que tu appelles faire hériter les droits du dossier parent aux sous-dossiers enfants, c'est l'extension récursive des droits d'un répertoire à la profondeur de l'arborescence des éléments inclus - ce qui est parfaitement géré sur un Mac dans OS X (et plus largement dans tous les Systèmes de type UNIX), que ce soit en ligne de commande (via le «Terminal») ou en mode graphique (via la Fenêtre d'Information du Finder).
Comme tu n'as probablement pas envie de quitter ta session admin courante, pour te loger dans la session root afin d'opérer en qualité d'avatar graphique du System Admnistrator qui ne connaît pas de "sens interdits" et effectuer ainsi tes manipulations sur des répertoires interdits autrement à l'admin que tu es ; je suppose que c'est une extension permanente des droits attachés aux répertoires concernés, avec application récursive à la profondeur de leurs éléments inclus, qui t'intéresse. Ce procédé porte un nom dans OS X : c'est ce qu'on appelle recourir aux ACL (Access Control Lists = Listes de Contrôle d'Accès), qui, par rapport aux droits basiques et carrés n'établissant jamais qu'un seul et unique accédant propriétaire (= user) sur un objet logique (= tableau des droits POSIX) ; permettent d'assouplir cet état de droits en y adjoignant des privilèges supplétifs : à savoir, ici, un utilisateur co-propriétaire de l'objet logique considéré, qui peut avoir les mêmes droits pléniers que l'utilisateur propriétaire POSIX et donc les mêmes privilèges d'accès. L'intéressant dans ce procédé, c'est que l'utilisateur co-propriétaire (auquel le privilège d'un accès supplétif est reconnu a priori par les attributs de droits accompagnant l'objet logique) peut, sans quitter sa propre session graphique (et donc sans aller se loger dans une session root), accéder directement sans "sens interdits" aux objets (dans toute leur profondeur) auxquels l'accès lui est reconnu dans les Listes de Contrôle d'Accès.
--------------------
Si tu veux opérer ce type de manipulation en ligne de commande, je te donne la syntaxe générique pour une commande dans le «Terminal» :
Bloc de code:
sudo chmod -R +a "ton_nom_d'utilisateur allow read,write,delete,execute" /chemin_au_dossier/nom_du_dossier
[comme tu invoques ici sudo avant le verbe de la commande, càd. Susbtitute User DO : opérer en qualité d'utilisateur substitut du System Administrator root --> tu dois t'authentifier par ton mot-de-passe admin pour te voir attribuer ce privilège provisoire. Donc, après ↩︎ (appui sur la touche "Entrée" du clavier pour activer la commande, une demande de password s'affiche --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> hop! la commande s'exécute - pour autant qu'elle soit formellement valide - pour le meilleur ou pour le pire selon la pertinence de son concept].
Je te commente la syntaxe de cette commande, afin que tu puisses l'adapter à ta guise :
chmod : ce verbe invoque le programme UNIX du même nom (abréviation de change mode : modifier la modalité des permissions)
-R : cette option ajoute l'extension récursive sur toute la profondeur de l'arborescence de l'objet (et n'est donc valide que si l'objet est un répertoire et pas un fichier)
+a : cette option introduit une addition aux ACL, càd. l'ajout d'un privilège supplétif aux droits POSIX relatifs à l'objet
"-----" : l'encadrement entre guillemets droits "" définit la fenêtre d'énoncé des différents paramètres à ajouter aux ACL en ce qui concerne l'objet
ton_nom_d'utilisateur (terme auquel tu substitues bien entendu ton véritable username tel que tu le lis dans l'invite de commande de la fenêtre du «Terminal» de type : MacBook Pro:~ mikeroy$) : c'est l'énoncé initial du "bénéficiaire" de l'ajout aux ACL (note que ce pourrait être aussi bien un groupe au lieu d'un utilisateur, par exemple : admin)
allow : il s'agit de la modalité de l'ajout aux ACL --> ici = "autoriser" (c'est ici une modalité positive ou affirmative). Ce pourrait être aussi bien un "ajout négatif" et dans ce cas allow devrait être remplacé par deny = "refuser" afin de priver un utilisateur spécifié ou un groupe de telle ou telle permission sur l'objet
read,write,delete,execute : il s'agit ici du "contenu permissif" qui se trouve attribué (si modalité = allow ; refusé si modalité = deny) au bénéficiaire relativement à l'objet. J'ai ici donné la "totale" (lire, écrire, supprimer, exécuter), mais il est possible de n'attribuer qu'une ou plusieurs de ces permissions --> il suffit de les aligner sans espace libre, avec une seule virgule en séparation : exemple read,execute.
/chemin_au_dossier/nom_du_dossier : il s'agit de l'adresse de l'objet (son chemin d'accès + son intitulé). La méthode graphique simple de le renseigner quand on a l'objet à disposition du pointeur et que la rédaction serait longuette, est de faire carrément un glisser-déposer au pointeur de l'objet dans la fenêtre du «Terminal», ce qui renseigne automatiquement le chemin à l'objet et le nom de l'objet
[NB. Il est possible de passer des commandes plus fines en terme d'ajout aux ACL, mais je me figure que la syntaxe assez "carrée" que j'ai détaillée a des chances de correspondre à ton souhait.]
--------------------
En mode graphique, il te suffit de sélectionner le dossier qui t'intéresse et de faire ⌘I dessus afin d'ouvir une Fenêtre d'Information du Finder --> tout en bas, tu avises une section intitulée : Partage et permissions --> déverrouille le cadenas d'admnistration avec ton mot-de-passe admin et alors :
- presse le bouton + tout en bas à gauche --> c'est l'équivalent graphique de demander d'opérer un ajout aux ACL sur l'objet : tu vois s'afficher en position surplombante un tableau des Utilisateurs et groupes dans lequel tu peux, par exemple, concernant un objet dont tu n'es pas l'user propriétaire, sélectionner ton propre nom d'utilisateur admin afin de l'ajouter comme utilisateur co-propriétaire de l'objet (bouton "Appliquer"), ce qui rajoute cet utilisateur dans le panneau de la fenêtre principale.
- en sélectionnant ce nouvel utilisateur co-propriétaire (= toi), tu peux manipuler l'onglet des permissions adjacent afin de régler celles que tu veux ajouter à ce co-propriétaire = toi-même dans la liste des ACL (tu as le choix de lecture et/ou écriture - note que la permission d'exécution est graphiquement indisponible).
- enfin, en pressant le bouton au logo d'engrenage ✱ tout en bas, tu peux choisir l'option : Appliquer aux éléments inclus et valider, ce qui est l'équivalent graphique de l'option récursive : -R en ligne de commande [NB. Cette option mérite d'être employée avec prudence dès que l'objet logique appartient à l'architecture de l'OS : càd. en ayant réfléchi à sa portée au préalable, car une erreur est difficile à rattraper ensuite sur une arborescence du Système. Mais s'il ne s'agit que de dossiers incluant une arborescence de simples "données" d'utilisateurs, il y a moins de risques].
♧
