problème de permissions

pickwick

Membre expert
Club iGen
1 Octobre 2001
4 618
208
70
Genève
aucoeurdumac.com
Bonjour,
J'avais un problème de session utilisateur corrompue (A). J'ai créé une seconde session (B).
J'ai activé ROOT et depuis ROOT j'ai transféré via le finder le contenu de chacun de dossiers bureau, documents, musique, images, etc.... de A vers ceux de B.

J'ai ouvert la session B et j'ai eu des soucis car les dossiers et fichiers transférés restaient la propriété de A et rien ne fonctionnait correctement : Itunes library, bibliothèque photos. etc.....

Si je peux changer le propriétaire d'un dossier, je ne vois pas le changement se propager automatiquement vers tous les dossiers et fichiers en aval, et il est impossible de le faire à la main.

Ma question est : comment réparer ce problème de permissions, c'est à dire rendre B propriétaire de tous les dossiers et fichiers transférés ?

Pour plus de sécurité j'ai depuis Root transféré tout l'utilisateur B vers un disque externe dont j'ai coché "ignorer les permissions du volume" et je pense qu'une fois tout cela copié, je pourrais toujours transférer à la main tous mes fichiers du disque externe vers la session B....

Mais n'y a -t-il pas plus rapide et plus simple ?
 
Je dirais que le moyen le plus rapide est soit le Finder, soit PathFinder (pareil) soit Terminal et la commande chown.

Pour cette dernière : en admettant que le nom court de l'utilisateur (B) est brol, et que tu es loggé avec un compte administrateur, tu ouvres Terminal et tu tapes :
Bloc de code:
sudo chown -R brol "/Users/brol"
sudo te demandera éventuellement un mot de passe (celui du compte sous lequel tu t'es loggé), à taper à l'aveuglette (on ne voit aucun caractère s'afficher : c'est normal).
Tu remplaces évidemment brol par le bon nom court. Tu fais bien attention à ne pas oublier les doubles quotes, à ne pas ajouter d'espace inconséquent etc.
Et ça devrait déjà mieux fonctionner, même si ce n'est pas tout à fait assez fin.
 
Merci bompi.
2 questions : qu'ai-je mal fait pour avoir ce problème de permissions ?
et comment via le Finder puis-je aussi résoudre ces soucis (aurai-je du passer par le système des boites de dépôt ?) plutôt qu'en activant Root ?
 
Je n'utilise pas l'activation root parce qu'elle n'est pas nécessaire.

Tu n'as pas fait d'erreur : simplement, copier ou déplacer un fichier (en général) ne change pas son propriétaire ni son groupe. Donc copier un fichier de l'utilisateur (A) depuis sa bibliothèque vers la bibliothèque de l'utilisateur (B) n'en fait pas un fichier de l'utilisateur (B). Il faut ensuite modifier son propriétaire (commande chown).

Normalement, avec le Finder, il "suffit" de sélectionner la maison de (B) et d'afficher ses informations. Ensuite de modifier les droits et/ou le propriétaire (tout en bas du pop-up qui s'est ouvert) et de les répercuter. Mais je ne suis pas habitué à utiliser cette méthode, étant un utilisateur du shell pour ce genre de choses.
 
et de les répercuter.....

oui mais c'est tout le problème, je n'ai pas su ou pas vu, sur ce pop-up, comment faire pour répercuter les droits en aval....
En tout cas je vais voir ce soir avec le terminal et je te dirai si cela a fonctionné.
Merci encore
 
Apple nous propose dans un cas comme le tien de passer par la réinitialisation des ACL sur le dossier d'Utilisateur : ça rétablit habituellement d'un coup tous les bons droits d'un compte.

On passe par Recovery HD (Cmd+R) > Terminal pour y taper resetpassword
et accéder ainsi à l'utilitaire de réinitialisation des mots de passe,
dont le dernier menu permet le reset des ACL sur le dossier d'Utilisateur de notre choix.

Ou par Onyx > Maintenance > Permissions, qu'on lance depuis le compte à réinitialiser.
 
Merci François, j'ai bien sur pensé ce matin à réparer les autorisations, mais cela n'a rien donné, je n'ai peut-être pas lancé Onyx depuis le bon utilisateur. Je vais tenter tout cela ce soir et vous tiens informé des résultats, merci !
 
Dans Maintenance > Permissions, Onyx offre un menu à cocher pour réinitialiser les ACL et les permissions du dossier de départ : c'est lui qu'il te faut cocher.
 
Alors.... j'ai essayé la solution du terminal, puis la solution de Onyx et le résultat c'est que certains dossiers n'ont pas récupéré leur bon propriétaire : Documents, Images, .... et qu'Aperture refuse de se lancer pour un problème de permissions..... que je n'ai pu réparer à la main sur le Aperture Library.
Alors c'est finalement en utilisant celle clonée auparavant sur le disque externe avec la case "ignorer les permissions" cochée que j'ai pu récupérer Aperture et utiliser la librairie pour Photos...
Comme quoi il n'y a pas de solution miracle et que dans certains cas il faut appliquer plusieurs "matchs" pour arriver à un résultat correct.. l'informatique est loin d'être binaire !!
 
Il y a un verrouillage de certains éléments du compte qui peut y empêcher la réinitialisation des ACL : on s'en sort alors avec le Terminal (sudo chflags -R nouchg /Users/le_compte), avant de recommencer la réinitialisation.
J'aurais dû t'en prévenir, mais, bon, tu t'en es sorti tout seul. :)

Le plus simple eût été, au départ, de faire transiter les données du compte A vers le compte Invité, avant de les rapatrier dans le compte B,
ou, en cas d'espace indisponible insuffisant dans le disque interne, de transiter par un disque externe.
Encore qu'il faut parfois y ajouter ensuite une réinitialisation des ACL !
 
Ok, merci à tous.
Là encore cela montre qu'avec du temps on arrive à tout sur le mac...
Mais que c'est parfois plus compliqué qu'on le pense au départ ;-) et là les forums sont vraiment d'une grande utilité !
 
Exercice rhétorique à prendre cum grano salis

:coucou: pickwick :coucou: bompi :coucou: François

J'ai suivi ce fil depuis les coulisses et je m'avoue déconcerté par la suite des événements, rien ne semblant se passer conformément aux attentes les plus "légitimes".

- a) D'abord, je ne comprends pas du tout pourquoi la commande proposée par bompi pourrait bien ne pas marcher holistiquement sur l'objet-cible : le répertoire global de l'utilisateur (que nous continuerons d'appeler : brol). En effet, elle impose en droits root une rectification récursive de l'user propriétaire sur toute la profondeur de l'arborescence du répertoire de brol. Comment pourrait-il se faire que le propriétaire de sous-dossiers directs (comme Documents ou Pictures) n'ait pas été rectifié à brol par cette commande récursive ?

Je ne vois pas du tout comment un attribut d'immutabilité (le flag:uchg) aurait pu venir verrouiller l'état de pareils items contre toute opération d'écriture, cela simplement parce que l'avatar d'utilisateur graphique de root aurait procédé à une recopie de fichiers à l'intérieur de ces sous-dossiers.

Je ne vois qu'une raison : si la commande a été passée dans le «Terminal» de la session d'utilisateur graphique de root, alors le libellé :

Bloc de code:
sudo chown -R brol "/Users/brol"
est invalide, car la mention sudo est contradictoire du statut de root qui n'a pas, dans son avatar graphique, à se demander à lui-même en tant que Super-User Logique le droit de procéder d'après ses propres droits. L'utilisateur graphique root est l'avatar immédiat du Super-User logique. C'est comme le cocher divin du char d'Arjuna, dans la Bhagavad Gîtâ : il est le dieu Krishna sous forme d'avatar. Par conséquent, en tant que cette incarnation (graphique), il n'a pas à requérir la permission d'être le Principe dont il est l'avatar. Mais ne nous égarons pas... Une commande sudo ... dans le «Terminal» de la session graphique root est rejetée car l'option sudo y est déplacée et donc absente.

Il faudrait donc, dans le «Terminal» de la session graphique de root, passer les 2 commandes suivantes :

Bloc de code:
chflags - R nouchg /Users/brol
chown -R brol:staff /Users/brol

(en remplaçant les 3 occurrences de brol par le nom court véritable de l'utilisateur concerné). Sinon, c'est dans le «Terminal» d'une des session admin d'utilisateurs qu'il convient de libeller ainsi les commandes :

Bloc de code:
sudo chflags - R nouchg /Users/brol
sudo chown -R brol:staff /Users/brol

--------------------
- b) mais voici plus croquignolet. J'ai réitéré maintes fois naguère l'expérience suivante : étant donné 2 utilisateurs admin expérimentaux : brol et toto, créés ad hoc, dont les Cartes d'Identités Logiques portent a priori en mention du chemin au dossier de départ d'utilisateur (permettant d'ouvrir une session graphique) : respectivement /Users/brol & /Users/toto --> modifier dans la Carte d'Identité Logique de brol le chemin à son dossier de départ de /Users/brol à /Users/toto suffit, au re-démarrage, pour imposer récursivement l'user : brol à la profondeur de l'arborescence du dossier de départ possédé par le ci-devant user : toto.

Pourquoi cette appropriation récursive du dossier de départ avec son contenu à l'utilisateur substitué (car telle était la règle politique que j'avais naïvement tirée de ces expérimentations) n'a-t-elle pas opéré dans le cas de pickwick ?

Puisque je n'en suis pas à une métaphore près (figure rhétorique incarnant par excellence la puissance de la récursivité dans l'imaginaire) - n'a-t-on pas affaire ici à une différence analogue à celle d'une usurpation du pouvoir d'État vs une immigration clandestine inassimilée ? Si, un espace national constitué, j'envisage un usurpateur s'emparer du pouvoir par un coup d'État (par exemple De Gaulle), alors s'ensuit une révision générale du cadre légal chargée de propager à toute la profondeur de l'espace politique la légitimité neuve de l'usurpateur (la Constitution de la Vè République). Si par contre, un espace national constitué avec un Chef d'État exerçant légitimement le pouvoir sans qu'intervienne aucun changement à la tête de l'État, j'envisage une immigration clandestine introduisant après coup une population non-assimilée - il est clair que la légalité antérieurement propagée se trouve ici contredite par l'importation a posteriori d'éléments inassimilés.

(Je prie le lecteur de ne voir absolument aucun "programme politique" suspect s'esquisser à travers ce petit exercice métaphorique, l'auteur adhérant a priori à la déclaration de Nietzsche : «L'État est le plus froid de tous les monstres froids, et il ment froidement en déclarant : Moi, l'État, je suis le Peuple»)

Je pense que pickwick a créé un "mouvement migratoire" local dans le cadre légal préconstitué d'un dossier d'utilisateur, si bien que sa population de fichiers immigrés est restée fidèle à ses premiers usages. Pour restaurer une "légalité universelle", il aurait fallu procéder après coup à la violence d'une "usurpation légitime" par le haut : après avoir édité dans la Carte d'Identité d'Utilisateur de brol (Panneau des Préférences Système/Utilisateurs et groupes --> sélection du nom d'utilisateur avec la touche ctrl pressée --> Options avancées... qui donne accès graphiquement à cette Carte d'Identité) le chemin au dossier de départ de brol de /Users/brol à /Users/toto (nécessité de créer un compte admin bidon pour ce faire) et re-démarré dans cette session forcément vide, car neuve (expérience équivalente à un exil) ; ré-éditer dans la Carte d'Identité d'Utilisateur de brol le chemin à son espace politique : de /Users/toto à /Users/brol da capo --> cette "usurpation légitime" (équivalant à un retour d'exil au pouvoir de l'ancien chef d'État) aurait vraisemblement exercé un effet législatif récursif : la propagation à la profondeur de l'arborescence du domaine de l'autorité du nouvel Utilisateur.

--------------------​
 
Dernière édition par un modérateur:
Excellent.... même si coté technique je n'ai pas tout compris !!! Je vois en effet comment j'aurai pu faire mais bon , tout cela parce que l'interface du premier utilisateur était comme passée à la machine et que je croyais la session corrompue.... Résultat 4 heures de travail : sauvegardes, essai des différentes méthodes, lancement de photos qui refuse la librairie aperture, tentative ok cette fois sur la library sauvegardée sur un disque ou on ignore les permissions, bref.... j'en passe et des meilleures.....
Parfois le mieux est l'ennemi du bien... quoique voir plus longtemps les fenêtres du Finder comme elles étaient.... ce n'était plus possible....
En tout cas merci pour ces échanges fort intéressants et remplis d'humour ;-)
 
J'ai suivi ce fil depuis les coulisses et je m'avoue déconcerté par la suite des événements, rien ne semblant se passer conformément aux attentes les plus "légitimes".

- a) D'abord, je ne comprends pas du tout pourquoi la commande proposée par bompi pourrait bien ne pas marcher holistiquement sur l'objet-cible : le répertoire global de l'utilisateur (que nous continuerons d'appeler : brol). En effet, elle impose en droits root une rectification récursive de l'user propriétaire sur toute la profondeur de l'arborescence du répertoire de brol. Comment pourrait-il se faire que le propriétaire de sous-dossiers directs (comme Documents ou Pictures) n'ait pas été rectifié à brol par cette commande récursive ?
:coucou:Macomaniac

Je l'ai constaté plusieurs fois : la réinitialisation des ACL après des manœuvres douteuses de la part de l'utilisateur requiert souvent un déverrouillage préalable.
Constaté, mais pas expliqué…

Deux voies me semblent offertes :
- les ACL prennent le pas sur les permissions POSIX (rwx natives), et le sticky bit peut prendre le pas sur les ACL d'un dossier : alors, j'imagine qu'un verrouillage puisse bloquer l'accès aux ACL :rolleyes:
(remarquons qu'il n'y a pas de t ou T de sticky bit dans les droits, mais seulement un +)

- le dossier Documents de mon compte a comme droits : drwx------+ moi staff
avec une ACL : 0: group:everyone deny delete
ce qui serait (du fait de l'absence de droits octroyés à staff et donc à system, ou parce que faire sauter l'ACL anti-destruction aurait la même valeur que la destruction elle-même ??) source d'un verrouillage de ces permissions :wideyed:
 
ouah ouh.... cela devient chaud cette discussion entre shellistes.... c'est Shell que j'aime ;-)
Pas trop de mon coté en tout cas....
Mais bravo encore pour vos efforts et vos échanges !
 
S'il fallait imaginer François :coucou: dans un rôle de Mousquetaire, je proposerais Aramis pour la finesse du jeu d'épée (pour ce qui est de d'Artagnan, je n'ai jamais eu de mal à me figurer chaussé des bottes de cet impétueux jusqueboutiste - en étant, de Gascon, un de pure souche...)
361608_original.png


En lisant le message #14 sur les ACL, j'ai eu une impression troublante de déjà-vu et une courte recherche m'a renvoyé à ce fil de MacGénération : ☞Problème de permissions suite à une restauration Time Machine☜ où nous eûmes déjà un échange sur le sujet (messages #18 & #19).

Si je scrute l'argument de François --> l'insuccès de la commande récursive chown ciblée user de bompi, concernant un certain nombre d'objets du répertoire HOME de brol, aurait été dû à un effet de verrou des permissions POSIX par l'ACL comportant une entrée (ACE) restrictive associée à ces objets. Et la présence d'un sticky bit aurait, par ailleurs, empêché la ré-intialisation de ces ACL. Double verrouillage, en somme : sticky bit --> ACL --> POSIX.

En ayant relu, pour me rafraîchir la mémoire, le message #18 que j'avais rédigé dans le fil pré-cité - voici ce qui m'apparaît : chaque objet d'OSX étant a priori associé à une ACL (liste de méta-permissions par rapport aux permissions POSIX de base), cette liste peut offrir 3 états : a) être vide (aucune "Entrée" = "ACE" n'est mentionnée dans la liste introduisant une méta-permission quelconque) : b) comporter au moins une entrée permissive (une ACE ajoutant une capacité d'action positive à un accédant, soit déjà présent dans le triplet POSIX, soit surajouté à ce triplet) ; c) comporter au moins une entrée restrictive (une ACE soustrayant une capacité d'action à un accédant de la même sorte).

Une ACL vide d'entrée n'induit aucun effet. Une ACL n'incluant que des entrées permissives n'induit aucun effet bloquant en soi sur les permissions POSIX de base, puisqu'il ne s'agit que d'une extension "positive" (qui peut le plus peut le moins). Une ACL incluant une ou plusieurs entrées restrictives induit un effet bloquant sur les permissions POSIX de base, mais dans un mode strictement circonstancié.

Je m'explique sur un exemple : j'ai un dossier dont les droits POSIX de base dont : 755 brol staff everyone (l'user:brol peut lire/écrire/exécuter l'entrée au répertoire ; le group:staff peut lire/exécuter l'entrée au répertoire mais pas écrire ; le group:everyone peut, pareillement, lire/exécuter l'entrée au répertoire mais pas écrire). Dans l'ACL associée à cet objet, il existe une entrée restrictive concernant le plus faible des groupes : everyone, disant : deny delete (soustraction de la permission de détruire l'objet).

Comment se manifeste l'effet bloquant induit par cette entrée restrictive ? De 2 façons : en ce qui concerne everyone, l'interdiction de détruire le dossier est absolue ; mais cette interdiction qui ne concerne a priori que everyone affecte relativement la capacité pour les autres accédants du triplet POSIX à exercer la même permission dont ils ne subissent, intrinsèquement, aucune restriction --> il leur faut s'authentifier par un mot-de-passe admin pour avoir le droit de l'exercer, ne serait-ce que parce que le plus faible des accédants (everyone) est affecté par une entrée restrictive concernant la permission de détruire l'objet (le dossier). Par voie de conséquence, si brol, l'user, est membre du groupe admin, il peut s'authentifier et donc exercer sa permission de détruire ; de même, tous les membres du groupe staff accédant à ce dossier qui sont par ailleurs membres du groupe admin, peuvent comme brol s'authentifier et exercer leur permission de détruire le dossier ; mais ceux des membres du groupe staff qui ne sont pas également membres du groupe admin, ne pouvant pas s'authentifier, sont condamnés par l'ACE restrictive "deny delete" de everyone à ne plus pouvoir exercer non plus leur permission de détruire le dossier.

Cette propagation de la restriction d'une permission affectant un seul des participants du triplet POSIX de base à la capacité pour les autres de la faire jouer automatiquement a-t-elle une portée au-delà de l'obligation de s'authentifier pour la faire jouer ? Mes différentes expérimentations sur des objets créés ad hoc (dossiers et fichiers) me montrent que non : car qu'est-ce que s'authentifier par un mot-de-passe admin ? C'est, dans le mode graphique, l'équivalent d'une authentification en ligne de commande dans le «Terminal» : obtenir circonstanciellement les droits de root - le Super-Administrateur Système. Or root, de par son statut d'Autorité Absolue, ne peut pas se trouver limité par des entrées restrictives dans l'ACL d'un objet (sans contradiction logique de son identité). root de supporte pas d'être concerné par une entrée (ACE) dans une ACL, ni en mode permissif, ni en mode restrictif, puisqu'a priori il a toutes les permissions y compris spéciales sans aucune restriction.

Or, comme s'authentifier pour un admin consiste à exercer l'autorité de root en mode circonstanciel, il est clair qu'un admin qui ferait l'objet d'une entrée restrictive dans une ACL relativement à un objet ne peut pas, absolument parlant, se trouver par là bloqué dans l'exécution de la permission concernée, puisqu'il a toujours la possibilité de surclasser son statut en passant en droit root : le blocage reste relatif : l'admin se trouve obligé de s'authentifier pour exercer la méta-permission dont il subit la restriction.

Les restrictions d'ACL ne sont donc des absolus que pour les accédants qui ne peuvent pas s'authentifier, càd. accéder circontanciellement aux droits de root. Pour ceux qui le peuvent (les admins) aucune ACE les concernant n'est un blocage absolu, mais seulement relatif (qui prend donc une valeur d'avertissement : fais gaffe avant de passer en mode root pour exercer cette permission !).

chown fait partie des méta-permissions susceptibles d'intervenir dans une entrée d'ACL. Eh bien ! Le raisonnement que je viens de tenir sur l'exemple de la méta-permission delete s'applique aussi à la méta-permission chown. Affectée en mode restrictif à un accédant non-admin (incapable de s'authentifier), elle a une valeur absolue : impossibilité de changer les accédants à un objet. Affectée en mode restrictif à un accédant admin, elle ne lui impose aucune interdiction absolue, mais lui imposer de passer par une authentification pour faire jouer la permission chown. Ce, parce qu'au sommet de la pyramide, root n'est susceptible d'aucune entrée d'ACL, et parce qu'un admin, ayant la capacité de s'authentifier, s'assimile par là circonstanciellement à root : il ne peut donc se voir soustraire absolument, à cause de cela, la capacité d'exercer la permission chown, mais seulement relativement.

Seules les 3 permissions POSIX de base constituent des absolus relativement à un accédant : lire/écrire/exécuter. Leur absence équivaut à une non-permission. Mais pour ce qui est des méta-permissions d'ACL, elles ne sont jamais des absolus, dans leur mode restrictif, lorsqu'elles affectent un accédant admin, mais seulement des "freins" à une exécution directe : le passage par une authentification qui fait accéder aux droits root permet toujours d'outrepasser la restriction.


Cette argumentation tant soit peu touffue me conduit à tirer une conséquence logique : aucun jeu d'entrées dans l'ACL d'un objet (par exemple un sous-dossier du répertoire HOME d'un utilisateur) ne peut jamais constituer un blocage absolu à une commande exécutée en droits root (suite à une authentification de la part d'un admin ou directement par l'utilisateur root lui-même). Par exemple une commande chown qui était l'enjeu initial du débat. Un sticky bit peut-il avoir un effet de verrou sur une ACL au point d'empêcher le passage à l'authentification de la part d'un admin en cas d'entrée restrictive (par exemple "brol deny chown") ? Mes expérimentations ne montrent rien de tel : le passage en root s'exécute dans le «Terminal» et une commande chown est honorée quand bien même il y a un sticky bit + une ACE "deny chown" sur l'objet affectant l'admin protagoniste.

☞ Je persiste donc dans mon « étonnement philosophique » : je ne vois pas en quoi la commande récursive chown de bompi, exécutée en droits root, aurait été bloquée par une entrée d'ACL associée à certains objets du répertoire HOME de brol (le sous-dossier Documents ou Images)...

 
Dernière édition par un modérateur:
Je persiste donc dans mon « étonnement philosophique »
Je vais ajouter à notre confusion, mon cher d'Artagnan !

La réinitialisation des ACL d'un compte comprend dans l'ordre une réinitialisation de toutes les ACL du compte (sudo chmod -RN), puis une réappropriation des éléments (sudo chown), et la réécriture des ACL natives sur les sous-dossiers du compte (chmod +a "everyone deny delete").
 
:coucou: François.

Diverses sollicitations m'ont diverti de donner suite à cette conversation d'esprits un peu bien partis dans la lune - au goût de pickwick :coucou:

Allo la lune.... ici Houston.... ;-)

☞ Un petit pas à l'échelle des ACL, mais un grand pas pour la mise-à-jour du «Système du docteur Goudron et du professeur Plume»
413669_original.gif

mais comme elle continue de me rôder confusément dans l'esprit, je profite d'une opportunité pour y revenir.

--------------------
Si l'ordre de succession des commandes dans l'opération de ré-intialisation des ACL d'un compte d'utilisateur (chmod de suppression de toutes les entrées d'ACL --> chown de réappropriation à l'user --> chmod restrictive de "delete" pour everyone) était logiquement nécessaire - cela signifierait que l'existence en mode récursif d'une entrée restrictive "everyone deny delete" dans les ACL d'un compte d'utilisateur brol bloquerait a priori la possibilité d'exécuter une commande chown récursive sur l'arborescence de ce compte. Vider d'abord les listes d'ACL de cette ACE restrictive serait la condition logique permettant l'exécution d'une commande récursive chown portant sur l'user.

Or je ne pense pas que cet ordre de succession soit nécessaire, mais contingent en ce qui concerne le temps d'intervention de chown. Càd. que la commande récursive chown n'est pas conditionnée dans sa possibilité par quelque entrée d'ACL restrictive que ce soit, qu'il faudrait faire sauter au préalable pour qu'elle puisse être honorée.

J'avance 2 arguments à l'appui de cette idée :

- a) un argument de fait : étant donné un dossier de départ d'utilisateur brol créé ad hoc, présent dans le répertoires des Utilisateurs de mon OS «Yosemite» ; je vérifie que les sous-dossiers du compte (genre : Documents etc.) sont bien chacun associés à une ACL comportant l'entrée : "everyone deny delete". Je force la note, en passant même une commande : sudo chmod -R +a "admin deny chown" /Users/brol --> si j'écris dans le «Terminal» à présent (logé dans ma session admin : macomaniac) une commande récursive chown en droits root du type : sudo chown -R macomaniac:admin /Users/brol ; alors la commande passe sans problème après une authentification par le mot-de-passe admin malgré la présence d'une entrée d'ACL doublement restrictive : "everyone deny delete,chown" + une ACE : "admin deny chown" --> des ACE restrictives dans les ACL de l'arborescence d'un dossier de compte n'empêchent nullement la passation d'une commande chown en droits root.

- b) un argument de raison (raisonnement par l'absurde). Supposons qu'une entrée restrictive "admin deny chown" dans les ACL d'un dossier de compte interdise totalement dans le «Terminal» une commande chown pour tout membre du groupe admin quand bien même cette commande serait-elle préfixée de sudo ; alors comme une commande sudo consiste, pour un admin, à s'identifier circonstanciellement à root lui-même --> cela équivaudrait à dire qu'une entrée restrictive dans la liste d'ACL d'un objet pourrait constituer un blocage pour root lui-même. Or le statut de root est, logiquement, de n'avoir aucune restriction opératoire (ce qui signifie que root a priori ne peut pas être impliqué par la moindre entrée restrictive d'ACL). Par voie de conséquence logique nécessaire, il est absurde de supposer qu'un admin devenu circonstanciellement root via sudo puisse ne pas être investi plénièrement des droits root, car cela impliquerait une contradiction logique du statut de root même. On en conclut rationnellement que la seule obligation qu'impose à un admin une ACE restrictive de type : "admin deny chown" dans l'ACL d'un objet est d'avoir à passer en root via une authentification pour récupérer médiatement la capacité de passer une commande chown sur cet objet.​

--> le seul butoir à une action directe de root (et d'un admin passé en droits root) est l'Attribut d'Utilisateur Immuable (flag:uchg) sur un objet --> ce blocage reste relatif, puisque une commande chflags nouchg en droit root est capable de le faire sauter. Il s'agit donc d'un "frein temporel" à l'immédiateté d'une opération et non pas un blocage absolu.

[Plus sévèrement, l'Attribut Système Immuable (flag:schg) sur un objet constitue, lui, un blocage insusceptible d'être levé aussi en droits root une fois chargé complètement le Système de fichiers de l'OS impliquant cet objet --> il faut rétrograder à un stade où le Système de fichiers n'est pas encore plénièrement chargé, càd. se loger dans la session du Single User qui équivaut à un mode "Super-Duper User" surclassant le "Super-User"]

Je conclus de cet exercice d'argumentation que pour un objet donné, relevant d'un système de fichiers monté en permissions d'écriture (et pas en lecture seule) et non affecté par un Attribut d'Immutabilité, aucune ACL contenant quelque entrée restrictive qu'on voudra ne peut bloquer pour un admin l'exécution d'une commande impliquée par la restriction, dès lors que l'invocation de sudo suivie d'une authentification l'a identifié à root.

[Il semble que El Capitan introduise on boot (càd. comme boot-args en NVRAM chargé par l'EFI au démarrage et donc passé au kernel via le boot_loader : boot.efi) une restriction rootless une fois le système de fichiers de l'OS chargé et déployé. Mais l'argumentation ici exposée se cantonne à l'espace OSX classique dont relève «Yosemite». Et l'on notera qu'il est toujours possible dans le «Terminal» d'El Capitan d'imposer le boot-args : rootless 0, ce qui fait qu'après re-démarrage la situation dans El Capitan est redevenue classique.]
 
Dernière édition par un modérateur:
Continuons un peu notre conversation. ;)

Je ne sais pas dans quel ordre se succèdent les trois commandes lors de la réinitialisation des ACL par l'utilitaire dédié.
J'ai même imaginé que l'utilitaire passe bien par ces trois commandes (= je n'en ai aucune certitude : cf infra).

Tout ce que j'ai retenu, c'est ce que ces trois commandes (dans l'ordre que j'ai donné) ont dépanné du monde lors du passage à Leopard, avant que l'utilitaire d'Apple ne soit largement conseillé et utilisé
= elles m'ont permis de comprendre (grossièrement) ce que faisait l'utilitaire.


Avec un bémol que je retrouve dans mes notes à propos de Leopard : l'utilitaire ne réinitialisait alors que les dossiers natifs (= créés à l'installation par le système) du compte*,
mais aucun dossier ajouté par l'utilisateur à la racine de son compte ou dans son Bureau.
Ce qui ne correspond pas tout à fait aux commandes que j'ai rapportées…

* : particularité qui a pu disparaître depuis !