MacBook Pro recuperation de donnée inaccessible

lool pardon Jean c'est quand je fais un copier collé je ne modifie pas désolé mea culpa :) bon je pense alors prendre un ssd de 1to et ton boitier est bien beau je dois dire ...
Pas de soucis.

Fais ton choix en connaissance de cause et tu seras satisfait.

@+
 
bon ben un grand merci a toi Jean c'était vraiment sympa bonne fin de soirée a peut-entre a une prochaine ... si une fois tu as un soucis avec la photo c'est mon domaine ;-)
 
Je me permets une petite incursion dans ce fil > en me disant que ça ne devrait pas créer de perturbation dans la conversation entre Ray & Jean - puisque tous les problèmes semblent avoir obtenu des solutions pratiques.

C'est seulement le démon de la curiosité théorique qui m'anime.

En effet, Ray a soumis comme problème le fait que des dossiers du volume d'un disque externe étaient verrouillés par des sens interdits --> ce qui signale toujours un problème de permissions.

Ma Dalton
a alors suggéré d'ouvrir une fenêtre d'information du Finder sur le volume recelant les dossiers récalcitrants > et de cocher l'option : "Ignorer les autorisations de ce volume". Cette option fait merveille d'ordinaire > parce qu'elle force le montage du volume-cible avec l'utilisateur connecté qui a ouvert sa session comme propriétaire par provision de toute la profondeur d'objets du volume. La question de permissions insuffisantes de Ray aurait donc dû être résolue par cette option.

Or Ray a signalé qu'il n'en était rien > les dossiers gardant leur sens interdit. Puis, après un échange de conversation avec Jean > Ray a fait part de la solution qu'il avait trouvée :
je viens de trouver une solution je vais sur chaque fichier qui a un sens interdit et la "lire les info" et ensuite le everyone je l'autorise en écriture et lecture et du coup les sens interdit s'enlève

Le problème ne concernait donc pas les permissions spécifiques de l'utilisateur Ray sur les dossiers > mais les permissions du groupe secondaire everyone. Étrange, non, qu'un utilisateur ne puisse pas accéder à un dossier (dont l'option : "Ignorer les autorisations de ce volume" l'intronise propriétaire par provision) > parce que le groupe secondaire everyone subit des permissions restrictives ?

Pour éclaircir ce point minuscule mais passionnant > je me suis livré à de petites manipulations de mon côté. Je crée sur mon Bureau de session un dossier intitulé BROL. Les permissions automatiques sur ce dossier sont : drwxr-xr-x (755 en valeur octale) macomaniac staff everyone. Je m'amuse à supprimer toutes les permissions de everyone sur le dossier > ce qui donne drwxr-x--- (750 en valeur octale) macomaniac staff everyone. Aucune conséquence sur macomaniac qui peut entrer dans le dossier comme au début.

Mais il s'agit là de ce qu'on appelle les permissions POSIX > càd. basiques sur l'objet. Que va-t-il se passer si j'introduis des permissions dites d'ACL (Access Control List : liste de contrôle d'accès gérant des permissions non plus basiques, mais supplémentaires) ?

Je passe dans le «Terminal» la commande :
Bloc de code:
chmod +a "everyone deny read,search,append" Desktop/BROL
qui inscrit dans la liste d'ACL du dossier BROL une triple restriction d'accès au compte du groupe secondaire everyone : interdiction de lire, chercher, attacher des sous-dossiers au dossier BROL. La conséquence graphique immédiate est que le dossier BROL s'orne d'un sens interdit ⛔︎ > qui fait que l'utilisateur-propriétaire macomaniac n'a plus la permission d'entrer dans le dossier pour en lire le contenu. Alors même que la restriction d'ACL ne le touche pas, mais le groupe secondaire everyone.

Il y a là une passionnante subtilité logique qui distingue les permissions POSIX (basiques) et les permissions d'ACL (supplémentaires) -->

  • dans les permissions POSIX > les permissions attachées aux groupes (staff et everyone) n'affectent en rien les permissions attachées à l'user (propriétaire) > parce que l'user en tant qu'user n'est pas considéré comme dépendant des groupes (alors qu'il est bien un membre de staff et un membre de everyone) > mais comme indépendant des groupes : il a un statut privilégié unique qui le distingue des groupes.

  • dans les permissions d'ACL > les permissions attachées aux groupes, y compris le plus faible (everyone) affectent directement les permissions de l'user (propriétaire) > parce que l'user n'est pas considéré comme indépendant des groupes > mais comme relevant également des groupes. Tout ce qui affecte les groupes l'affecte directement en tant que membre de ces groupes. Si le groupe everyone se voit affecté une interdiction stricte de lecture/recherche sur un dossier > alors l'user se voit directement affecté par cette interdiction en tant que membre du groupe everyone. L'interdiction de lecture à quiconque (everyone) étant radicale > cette interdiction surpasse l'autorisation POSIX de l'user de lire le contenu du dossier.

Je pense que c'était exactement la situation de Ray sur ses dossiers à sens interdits. Et j'ai pu constater que l'option : "Ignorer les autorisations de ce volume" (en copiant mon dossier BROL dans un volume où cette option était activée) > si elle modifie par provision les permissions POSIX > est incaptable de neutraliser les permissions d'ACL qui restent intouchées.

Avec une intuition logique sûre > Ray a testé dans une fenêtre d'information du Finder le fait de remettre le groupe secondaire everyone en permissions de lecture et écriture > et cela a fait sauter les sens interdits. J'ai testé la même opération sur mon dossier BROL > et le sens interdit a aussi été levé. Pour savoir quelle action cela avait sur les permissions d'ACL > j'ai passé une commande :
Bloc de code:
ls -led Desktop/BROL
qui les fait ressortir et j'ai obtenu un :
Bloc de code:
drwxr-xrwx macomaniac  staff  everyone /Users/macomaniac/Desktop/BROL

 0: group:everyone allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

--> il apparaît que le Finder se montre d'une générosité sans pareille > en ne se contentant pas de restaurer à lecture et écriture les permissions POSIX de everyone > mais en arrosant littéralement ce groupe de permissions d'ACL - dont list et search qui équivalent à une lecture pleine (il y a donc inversion des restrictions d'ACL en permissions d'ACL pour everyone).

Il y a un autre moyen de régler le compte des sens interdits découlant de restrictions d'ACL à everyone --> c'est de ré-initialiser carrément la liste d'ACL de l'objet en supprimant toutes ses entrées. Par exemple > je me suis amusé à passer une commande :
Bloc de code:
chmod -R -N Desktop
où j'attache à l'utilitaire chmod les 2 options de Récursivité et de Neutralisation des ACL en prenant pour domaine le dossier du Bureau --> immédiatement le sens interdit s'efface sur BROL > quand bien même everyone n'aurait aucune permission POSIX sur le dossier > parce qu'il n'a plus de restriction d'ACL en lecture sur le dossier > ce qui ne rejaillit plus sur l'user macomaniac en tant que membre du groupe everyone.

Une commande :
Bloc de code:
sudo chmod -R -N /Volumes/monvolume
aurait donc réglé d'un coup la question de Ray aussi bien > en supprimant toutes les entrées d'ACL sur tous les objets du volume.

En résumé : il y a interférence de restrictions de permissions d'ACL du groupe secondaire everyone sur l'user de l'objet. D'où sont venues ces restrictions d'ACL chez Ray : aucune idée. Un administrateur tenté d'introduire des restrictions d'ACL pour everyone sur des objets donnés > devrait anticiper leur rejaillissement sur l'user.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: pouppinou
whouawww la vous allez trop loin pour moi lol !! perso je n'ai agit que par logique et avec l'aide de Jean mais merci bcp macomaniac pour votre participation et déduction ;-)