Modifier le propriétaire d'un dossier - Maverick

[Membre supprimé 1060554]

Le fil étant résolu en pratique, on me passera ces prolongations théoriques...​

J'ai déplacé son répertoire perso dans le répertoire /Utilisateurs/VAL/Documents à son nom, depuis ma cession admin.

y a-t'il moyen de surveiller et agir sur le contenu des documents de mon fils (dans sa session VAL) depuis ma session admin ?
Lorsque j'y vais depuis le finder de ma session admin, il y a des petits sens interdit sur les dossiers de mon fils...

Un point problématique qui m'a échappé dans ce fil, depuis le début, est celui que soulève le conflit logique des déclarations citées :

- en fonction des droits POSIX réguliers dans OS X, l'utilisateur admin qu'on appellera ici tophe, lorsqu'il entre en mode graphique (Finder) depuis sa session admin dans le répertoire des Utilisateurs (/Users), a les permissions d'entrer au 1er degré dans l'espace du dossier de compte VAL (le dossier parent). Mais à partir de là, il ne peut pas régulièrement entrer dans les sous-dossiers (enfants) de ce compte (créés par le Système avec l'utilisateur VAL : Bureau, Documents, Images, Musique, Téléchargements, Vidéos) - à l'exception du seul sous-dossier intitulé : Public ouvert à des échanges de documents avec d'autres utilisateurs de l'OS.

- comment donc cette impossibilité d'accès, notamment au sous-dossier Documents du dossier VAL dans les Utilisateurs, a-t-elle pu être surmontée pour permettre la première opération décrite : « J'ai déplacé son répertoire perso dans le répertoire /Utilisateurs/VAL/Documents à son nom, depuis ma session admin », puisque le sous-dossier /Users/VAL/Documents était frappé d'un sens interdit ? Car, si j'ai bien compris, ce n'est pas un dossier présent à l'origine dans la session admin partagée tophe qui a été déplacé dans le dossier de compte VAL, mais son arborescence contenue de fichiers (éventuellement dans des sous-dossiers), lesquels auraient été déplacés à l'intérieur du dossier d'accueil Documents de VAL - n'est-ce pas ? Comment donc le sens interdit a-t-il été surmonté par tophe pour effectuer ce déplacement dans /Users/VAL/Documents - sens interdit reflétant graphiquement la situation de droits POSIX régulière sur le dossier Documents en question :

drwx------+  3 VAL   staff   /Users/VAL/Documents

où on observe que sur l'objet /Users/VAL/Documents (identifié par le d de directory = répertoire) on a pour l'user propriétaire VAL les permissions rwx (read/write/execute : lire, écrire, exécuter <l'entrée à l'espace du répertoire>), mais pour tout membre du groupe primaire staff : --- (ni lire, ni écrire, ni exécuter), et idem pour tout membre du groupe secondaire everyone <ou: other> : --- (ni lire, ni écrire, ni exécuter) ?​

=> Le procédé que je vois est que le déplacement aurait été effectué, non pas graphiquement (impossible, comme décrit), mais via une commande dans le «Terminal» utilisant l'élévation de droits sudo, du type :

sudo mv /Users/tophe/Documents/VAL/* /Users/VAL/Documents

--> tous les fichiers/sous-dossiers enfants (*) contenus dans le dossier parent /Users/tophe/Documents/VAL auraient été déplacés dans le dossier d'accueil du nouvel utilisateur : /Users/VAL/Documents, et, comme c'est l'opérateur tophe qui aurait effectué ce déplacement dans son shell en droits root, chaque fichier déplacé aurait gardé comme user propriétaire le tophe initial (puisque ces fichiers appartenant au départ au dossier de compte tophe relevaient de sa propriété).

Soit. Mais alors comment comprendre que quelqu'un capable de passer une commande de type : sudo mv dans le «Terminal», ne saurait pas passer une commande de type : sudo chown ("change_owner") qui est du même niveau logique élémentaire (non plus un "change_location" = mv, mais un "change_owner" = chown) ?

☞ maintenant que ton problème pratique est réglé, TopheLM, peut-être peux-tu éclairer ce point purement théorique rien que pour l'amour de l'art ?

♤
​

Il semble qu'outre un problème de droits POSIX basiques (instaurer VAL à la place de tophe en user propriétaire des fichiers/sous-dossiers déplacés dans /Users/VAL/Documents) ; un problème de droits d'ACL secondaires était en jeu, comme bompi l'a conjecturé à juste titre, puisqu'il il a fallu une commande de type :

sudo chmod -R -N /Users/VAL/Documents

pour libérer la capacité de VAL à manipuler à sa guise les fichiers hérités dans son dossier Documents. Commande dans laquelle, outre l'élévation de droits sudo, l'option récursive -R et la cible /Users/VAL/Documents déjà vus, on note que le programme invoqué est chmod (change_mode = modifier les permissions, et non plus chown : change_owner = modifier les utilisateurs) avec l'option -N (comme "Negation") qui commande une remise à zéro des droits d'ACL secondaires.

Une ACL (Access Control List) est un fichier invisible attaché à tout objet (fichiers/dossiers) dans OS X, et recelant zéro à n ACE (Access Control Entry) : il s'agit de permissions spéciales sur l'objet attachées à un accédant nominé (utilisateur ou groupe) et qui peuvent consister en "ajouts" (= ACE positive : par exemple, ajouter pour tophe une permission de lecture supplémentaire sur tel ou tel objet dont le propriétaire POSIX est VAL) ; ou en "soustractions" (= ACE négative : par exemple, retrancher pour le groupe secondaire everyone la permission de déplacer l'élément sur tel ou tel objet ciblé).

Des ACE "positives" (ajouts), par définition élargissent les permissions POSIX de base et, par suite, n'ont aucun effet rétroactif sur celles-ci. Il n'en va pas de même, a contrario, pour les ACE "négatives" (soustractions), lesquelles, asymétriquement, ont un effect rétroactif sur les permissions POSIX de base. Un exemple : supposons un dossier dont tophe est l'user en permissions POSIX rwx ; supposons que l'ACL de ce dossier comporte une ACE négative mentionnant pour le groupe secondaire everyone la soustraction spéciale de permission de déplacer des éléments dans ce répertoire (une soustraction donc à la permission globale d'écriture) => eh bien ! cette ACE négative qui ne cible que les membres du groupe "everyone" (n'importe qui) va, rétroactivement, affecter les permissions pléniaires rwx de l'user propriétaire tophe : pour exercer sa permission POSIX de déplacer graphiquement des fichiers dans ce dossier (impliquée par la permission d'écrire w), il va devoir s'authentifier chaque fois par son mot-de-passe admin, alors que l'ACE négative ne le ciblait pas nommément, mais everyone. Car ? Car tophe relève aussi comme quiconque du ce groupe secondaire everyone, et il a donc graphiquement désormais à prouver chaque fois qu'il n'est pas qu'un simple relevant du groupe everyone dans l'action de déplacer des fichiers, mais aussi l'user propriétaire tophe qui possède la permission POSIX légitime de ce faire.

Ainsi, la gestion des ACE négatives est-elle toujours astreignante en pratique, car elle force l'user des objets concernés à administrer chaque fois la preuve par mot-de-passe qu'il se démarque bien du groupe affecté par la soustraction spéciale de permission - ce, uniquement dans la classe d'action sur les objets relevant de l'ACE négative en question, mais nullement pour toute autre classe d'action non affectée par une ACE négative.

Il semble donc que c'était le cas pour les fichiers déplacés par tophe de son dossier de compte dans celui des Documents de VAL - mais alors, si l'aimable assistance a suivi les méandres argumentatifs de ma prose, voici la question qui se pose : si au moins une espèce d'ACE négative concernant la classe d'action : déplacer les fichiers et ciblant présumablement le group:everyone obligeait VAL à une authentification pour prouver qu'il se démarquait bien du "tout_venant" en tant que l'user propriétaire légitime des objets en question ; alors cette ACE héritée par ces objets lors du déplacement opéré par tophe depuis son dossier de compte aurait dû, ab origine, affecter pareillement l'utilisateur tophe lorsqu'il tentait d'opérer une action de la même classe (déplacer) sur les objets originaux concernés dans sa session. Ce, parce qu'un changement d'user propriétaire POSIX (de tophe à VAL sur les fichiers déplacés dans /Users/VAL/Documents) ne modifie absolument pas les entrées d'ACE des fichiers d'ACL associés à ces objets => si, par exemple, une ACE négative : "everyone deny move" affectant les fichiers déplacés dans le dossier de compte de VAL obligeait VAL à s'authentifier pour prouver qu'il était quelque chose de plus qu'un everyone et avait légitimité de déplacer ces objets en tant que leur user légitime => alors la même contrainte pesait au départ sur tophe (et tous ceux qui opéraient sous ce nom dans sa session) relativement à la classe d'action : déplacer, en raison de l'ACE négative : "everyone deny move" attachée à ces objets, et qui a été héritée par les objets déplacés dans le compte de VAL.

☞ d'où ma question : n'y avait-il pas déjà obligation de s'authentifier pour déplacer des fichiers lorsqu'ils faisaient partie du dossier de compte de tophe ?

♧​

 

[TopheLM]

ouch !
J'ai tout lu, pas tout compris (la fin...) alors je réponds.

voila comment j'ai procédé dans l'ordre :

Depuis la session admin d'origine (Tophe), j'ai créé un nouvel utilisateur VAL avec des droits standards.

Depuis Tophe, je voyais bien le dossier Users/VAL/... mais avec un sens interdit sur tous les sous-dossiers (dont Documents) sauf sur Public, donc impossible d'y mettre les fichiers.
Alors j'ai fait "Lire les informations" sur le dossier documents et ajouté une permission lecture/écriture à Tophe (admin)

J'ai ensuite pu déplacer les fichiers de Tophe vers Users/VAL/Documents.

Seulement ensuite, mon fils ne pouvait plus gérer ses fichiers depuis VAL sans autorisation admin.

D'où mon Post et la seule ligne qui a été efficace pour moi, le chmode.

Mon fils, de sa session VAL, peut maintenant gérer ses fichiers sans autorisation mais du coup, les sens interdit sont revenus dans Tophe sur les dossiers de Users/VAL/Documents.

Je n'ai pas osé remettre un permission lecture/écriture à Tophe sur le dossier User/VAL/Documents, de peur de me retrouver dans la même situation qu'avant le chmode...

 

[Membre supprimé 1060554]

Tophe.

Je m'étais figuré après coup que tu avais utilisé une fenêtre d'info du Finder pour accéder à l'espace du sous-dossier /Users/VAL/Documents (c'est ce qu'on appelle avoir l'« esprit de l'escalier » : trouver au moment de la sortie la répartie qu'il aurait fallu avoir au salon). Point de détail réglé.

♤​

- 1° les ACL. Ta manipulation dans la fenêtre d'info, qui a consisté à instaurer tophe en co-user en lecture/écriture/exécution (dernière permission = implicite) du sous-dossier Documents de VAL : c'est une manière graphique de greffer une ACE positive (un ajout de droits en ta faveur) dans l'ACL du dossier en question. Comme j'ai tenté de l'expliquer dans la 2è partie de mon topo, les ACE positives (ajouts) n'exercent jamais d'influence restrictive sur les droits basiques préétablis : ceux de l'user VAL sur le dossier. Ton ACE n'a donc eu aucune influence sur les problèmes de gestion de fichiers de ton fils (tu peux donc la rétablir si tu veux garder une porte d'entrée dans ses Documents).

Mais si tu en as profité pour instaurer une ACE négative sur le dossier pour le groupe secondaire (everyone), du type : dénier à everyone les permissions de lecture et d'écriture au dossier, et si tu as rendu récursive cette ACE (sur la profondeur de l'arborescence du dossier Documents), alors comme j'ai aussi tenté de l'expliquer une telle ACE négative exerce un effet restrictif sur les droits basiques préétablis. Car VAL, s'il a en principe des permissions plénières de lecture/écriture/exécution sur le dossier Documents et son contenu, relève aussi du groupe du everyone (comme tophe est à la fois le père de VAL mais aussi un Français parmi tous les autres : tu vois ?). De sorte que VAL, s'il a bien le droit en tant qu'user de référence de manipuler les fichiers dans Documents en lecture/écriture ; en tant que membre du everyone, n'a pas ces droits-là => une façon de résoudre ce conflit logique est la requête d'authentification, par laquelle VAL prouve au Système qu'il n'est pas qu'un membre du everyone, mais aussi l'user proprétaire récursif du dossier et de son contenu.

C'est la conjecture que je fais pour expliquer ces blocages de manipulations. Si elle ne collait pas, alors les ACE négatives était recelées dès le départ dans l'ACL des fichiers déplacés de tophe > VAL et se seraient trouvées héritées par les fichiers à la destination.

♧​

- 2° l'user. Mais, comme les fichiers déplacés dans Documents relevaient du dossier de compte tophe et avaient comme user propriétaire tophe (toi), le fait de les déplacer dans /Users/VAL/Documents n'avait nullement modifé cet user = tophe (toi) sur ces éléments individuels. Par suite, VAL était confronté à des fichiers dont il n'était pas l'user. Il n'avait donc sur eux que les droits d'un membre du groupe primaire staff ou du groupe secondaire everyone : càd. une simple permission de lecture et pas d'écriture. Il était donc obligé de s'authentifier par un mot-de-passe admin pour élever ses droits à ceux de root s'il voulait exécuter des actions dépassant la lecture.

♡​

=> j'en déduis que VAL n'avait pas qu'un problème d'ACL négative, mais aussi un problème de propriété directe (il n'était pas l'user des fichiers ni des sous-dossiers les contenant si c'est une arborescence qui avait été déplacée). Il fallait donc les 2 commandes : chown et chmod pour régler la question, le fait que la commande chown n'ait pas donné seule tous les résultats attendus ne prouvant pas que la commande chmod seule aurait réglé la question. C'est comme si j'avais un problème d'arrivée d'eau de chauffage central dans un radiateur parce qu'il y a de l'air dans le corps du radiateur qui empêche la circulation d'eau et parce que l'aiguille d'acier de la poignée thermostatique est bloquée par le tartre en position fermée en bloquant l'arrivée d'eau => il me faut à la fois dégripper la poignée thermostatique et purger le corps du radiateur afin que l'eau chaude non seulement puisse arriver mais aussi puisse circuler...

 

[TopheLM]

Wahou !
Quelle leçon !

Merci beaucoup pour ces explications, je crois avoir compris ce que tu expliques et pourquoi le chown m'a semblé inefficace...

Super d'avoir ici de tels connaisseurs. Bravo et encore merci.