Donc voilà , j'ai un vieux mac qui doit dater de 6/7 ans et récemment je n'arrive plus a ouvrir ma session , je met la mot de passe , sa charge un ecran bleu et sa me fait revenir vers l'ecran de selection des session , je n'ai aucun probléme pour ouvrir mon autre session ( toute deux admin ). j'aimerai savoir 2 choses : soit bien sûr comment re-ouvrir cette session ou alor comment recuperer des dossiers vraiment important qui était sur cette session , en sachant que m'ont lecteur de disque est cassé.
Je n'arrive pas a ouvrir ma session.
- Créateur du sujet Orbethak
- Date de début
Soit il y a une un traficotage de cette session (renommage petite maiseon, etc.), soit i y a une foultitude de fichiers sur le bureau de cette session, soit il y a un problème de droits (ACL) pour cette session (ce qui est réparable avec le DVD fourni avec la machine -qui ne lance plus les DVD si j'ai bien compris-)
et indiquer le type de mac( ppc macintel) et OS dessus
le traficotcage (malencontreux) es renommage de maison était assez"facile" sur anciens OS, il l'est moins sur les récents
le traficotcage (malencontreux) es renommage de maison était assez"facile" sur anciens OS, il l'est moins sur les récents
Ou un login item qui coince, comme dans http://support.apple.com/kb/TS4348?viewlocale=fr_FR
= là, il suffit de se connecter à la session en mode sans échec (Maj enfoncée à la connexion)
et, en cas de succès, de faire le tri dans les éléments lancés à l'ouverture du compte (ou de s'intéresser aux com.apple. loginitems et loginwindow .plist du compte).
Ou encore : http://support.apple.com/kb/TS1413?viewlocale=fr_FR
D
Deleted member 340362
Invité
Si tes deux sessions ont des droits administrateur et que je ne me trompe pas (ça arrive souvent, et contre mon gré), tu devrait avoir accès aux fichiers de la session qui ne marche pas par la session qui marche.
Deuxièmement, mon expérience, bien que je ne me considère pas encore comme un vieux, est qu'il ne faut jamais faire confiance à un support de stockage, quel qu'il soit. Cela peut lâcher du jour au lendemain sans prévenir, donc il est IMPORTANT DE FAIRE DES SAUVEGARDES DES DOSSIERS IMPORTANTS en double ou triple exemplaire.
Il est même conseillé (je ne le fais pas moi-même, donc c'est un conseil, pas une remontrance), d'avoir des sauvegardes dans des lieux différents (sauvegarde de ses photos précieuses de famille au bureau et sauvegarde de ses documents importants du bureau à la maison) en cas d'incendie ou autre...
Deuxièmement, mon expérience, bien que je ne me considère pas encore comme un vieux, est qu'il ne faut jamais faire confiance à un support de stockage, quel qu'il soit. Cela peut lâcher du jour au lendemain sans prévenir, donc il est IMPORTANT DE FAIRE DES SAUVEGARDES DES DOSSIERS IMPORTANTS en double ou triple exemplaire.
Il est même conseillé (je ne le fais pas moi-même, donc c'est un conseil, pas une remontrance), d'avoir des sauvegardes dans des lieux différents (sauvegarde de ses photos précieuses de famille au bureau et sauvegarde de ses documents importants du bureau à la maison) en cas d'incendie ou autre...
Via le Finder, il n'y a que le compte Root qui accède directement au contenu des autres comptes.
Via le Terminal, les comptes admin peuvent manipuler le contenu des autres comptes, certes,
mais s'ils peuvent le faire, c'est avec la commande sudo, celle qui les passe en mode root…
Dernière édition par un modérateur:
je me suis connecté en mode échec mais la non plus je n'arrive pas a acceder a mon compte donc je ne peut pas supprimer d'éléments , et pour la deuxième option , bhein mon lecteur de disque est cassé...
Q
quark67
Invité
Il existe une solution :
Dans le Finder, tu navigues vers le dossier
Bloc de code:
Macintosh HD/Utilisateurs/La_session_qui_ne_s'ouvre_pasÀ l'intérieur, tu verras les dossiers du compte inaccessible, avec le symbole de sens interdit (les noms de dossiers génériques, tels celui du Bureau, sont en anglais). Sélectionne un des dossier dont tu souhaite consulter le contenu.
Dans le menu Fichier du Finder, choisis Lire les informations.
Au bas de la fenêtre qui s'affiche, se trouve la zone « Partage et permissions » (clique sur le triangle en face pour qu'il affiche les détails).
Clique sur le cadenas, en bas à droite de cette fenêtre.
Entre le mot de passe de ton compte actuel.
Ensuite, clique sur le bouton « + » situé en bas de la fenêtre, avec le cadenas ouvert.
Dans le panneau qui apparait alors, choisis le nom de ton compte actuel.
Le nom de ta session apparait alors, avec comme privilège d'accès : « Lecture seulement » (tu peux changer cela, mais ce n'est pas nécessaire pour consulter et copier les éléments souhaités).
Si tu as beaucoup d'éléments à consulter, c'est peut-être un peu long de procéder ainsi...
Une autre solution qui donnerait accès à tous les éléments d'un coup, qui serait une solution un peu lourde suivant la taille des éléments dans le compte considéré mais qui serait une solution définitive, consiste à aller dans les préférences systèmes, rubrique « Utilisateurs et groupes », cliquer sur le cadenas, entrer le mot de passe de ton compte actuel, sélectionner le compte dans lequel tu ne parviens pas à accéder, puis cliquer sur le bouton « - » au bas de la fenêtre. Dans les choix proposés, choisir de faire une image disque du compte qui sera supprimé.
Une fois ceci fait, ce qui peut être très long si le contenu du compte pèse plusieurs dizaines ou centaines de Go, il restera à ouvrir l'image disque créée (et là aussi ça peut prendre pas mal de temps) et à y naviguer : tous les dossiers et éléments contenus dans l'ancien compte seront accessibles immédiatement.
J'ai fait le test avec un compte utilisateur créé uniquement à cette fin. Le compte créé ne contenant quasiment rien, le test fût rapide, et l'image disque ne pesait que quelques Mo. Je n'ai strictement aucune idée de ce que cela donne en situation réelle avec des comptes comprenant plusieurs centaines de Go de données. Cela pourrait être TRÈS long.
Q
quark67
Invité
M
Membre supprimé 1060554
Invité
Salut quark!
D'abord, permets-moi de te dire : Bravo!
pour l'ingénieuse double solution que tu as exposée à Orbethak et qui lui a permis sans difficulté de récupérer les dossiers importants de sa session bloquée.
Est-ce que tu me permets, à présent, de généraliser à partir de cet exemple? Comme je ne voudrais pas que cet exercice (un de mes favoris
) te soustraie le mérite d'«inventeur» dans l'espace de ce fil, je te propose plaisamment de parler à ce sujet de : «Paradoxe_de_Quark».
Comme on le sait, l'accès à chaque item dans OS X est réglé par des droits, lesquels définissent d'une part des Accédants et d'autre part des Permissions. Les Accédants se distribuent en 3 catégories : le Propriétaire (u = user), le Groupe (g = group) et les Autres (o = others) ; les Permissions se distribuent également en 3 sortes : Lire (r = read), Écrire (w = write) et Exécuter (x = execute). Par voie de conséquence, chaque item (fichier, dossier, application...) se voit associer des droits d'accès, qui sont ses attributs invisibles, déterminant qui a la permission de quoi regardant l'item.
Ce système s'applique à ces items que sont les répertoires d'utilisateurs et les sous-dossiers qu'ils contiennent. Permets-moi d'appeler toto le nom du répertoire d'un usager-admin dont la session n'est pas actuellement ouverte et bibi le nom du répertoire de l'usager-admin dont la session est actuellement ouverte. Si bibi va fouiner dans le dossier 'Utilisateurs', il tombe sur 2 répertoires : bibi (le sien) présenté graphiquement sous forme d'icône de petite maison blanche, et toto (l'autre) présenté sous forme de simple dossier.
Pour bibi, le répertoire bibi, s'il en lit les droits dans une fenêtre d'information du Finder, a les attributs suivants : bibi = lecture/écriture, groupe = lecture, autres = lecture. En ce qui concerne le répertoire de toto, la fenêtre d'information du Finder donne quelque chose de symétrique : toto = lecture/écriture ; groupe = lecture, autres = lecture. Comme bibi fait partie du groupe qui a des droits de lecture sur le répertoire de toto (le groupe : staff), bibi peut donc ouvrir le répertoire toto et browser son contenu.
Le contenu du répertoire toto pour bibi apparaît sous forme de dossiers (Desktop, Documents, Downloads, Library, Movies, Music, Pictures, Public) qui portent tous un sens interdit à part 'Public'). La fenêtre d'informations du Finder explique que seul toto a des permissions de lecture/écriture sur chacun des dossiers interdits, tandis qu'aucun groupe n'est référencé avec aucune permission, et que les 'autres' sont référencés aussi avec un accès personnalisé qui est égal à zéro. C'est la façon standard dont un répertoire d'usager qui n'est pas celui dont la session est ouverte se trouve protégé en terme de ''privacy' (confidentialité) par le protocole UNIX basique qui est POSIX et qu'OS X utilise comme standard.
Déjà cette situation en défrise plus d'un, parce que si les dossiers d'utilisateurs contenant les données personnelles sont protégés contre l'intrusion, l'espace du répertoire global d'utilisateur lui ne l'est pas (puisque bibi peut browser l'espace du répertoire de toto). On peut justifier cette perméabilité du répertoire global d'usager, par le fait qu'elle permet seule la présence d'un dossier 'Public' sur lequel, si toto a les permissions de lecture/écriture, le groupe (staff) ainsi que les autres ont des permissions de lecture. Cela permet à toto de proposer en consultation des documents à d'autres usagers quand la session de ces derniers sera ouverte, sans néanmoins que ces derniers puissent écrire dans l'espace du dossier 'Public' de toto.
À l'époque où d'innombrables personnes privées proposent en lecture publique une sorte de 'mise-en-scène' d'eux-mêmes (sur Facebook etc.), il n'y a rien de choquant à ce que, dans l'espace multi-utilisateurs d'un ordinateur, le répertoire d'usager de chacun soit ouvert en accès afin de permettre l'existence d'un dossier 'Public' offert en lecture à d'autres.
Là où on peut, néanmoins, déceler une 1ère faille de sécurité concernant la confidentialité des données personnelles d'un répertoire d'usager, c'est que le diabolique bibi (qui n'est pas né de la dernière pluie) s'est avisé qu'il peut utiliser le Finder pour demander une copie du répertoire global de toto (ou d'un de ses dossiers interdits) dans l'espace extérieur à ce répertoire (son propre répertoire, l'espace système, une partition, un DDE, tout ce que l'on voudra). Une fois effectuée, cette copie du répertoire (ou d'un dossier du répertoire) de toto est en lecture/écriture pour le diabolique bibi, car ce dernier étant l'auteur de la copie, il est donc devenu le propriétaire du dossier.
Par voie de conséquence, bibi peut lire le contenu de tous les dossiers qui sont interdits d'accès aussi longtemps qu'ils font partie du répertoire de toto. Il peut aussi les éditer (!), puisqu'il possède les droits d'écriture dessus, soit en modifiant leur contenu, soit en l'effaçant. Cela fait, le diabolique bibi peut très bien re-déplacer dans l'espace du répertoire 'Utilisateurs' le dossier toto qu'il a édité, et le Finder va se borner à demander si bibi veut remplacer le répertoire de toto par le nouveau du même nom. Si le diabolique bibi répond : oui, il peut ainsi, en renseignant un mot-de-passe admin, substituer au répertoire d'usager original toto un répertoire de sa propre fabrication, éventuellement vide.
Il y a là, manifestement, une grave faille de sécurité à l'égard de la confidentialité des répertoires d'usager dans OS X. Ce, parce que le Finder se voit attribuer des droits d'exécution (comme la copie et le collage dans mon exemple) qui équivalent à une véritable traversée des droits POSIX. C'est comme si, en mode indirect, le Finder donnait au diabolique bibi (qui s'en est avisé dans sa grande perversité) des permissions de lecture-écriture sur les contenus du répertoire d'usager de l'innocent toto. C'est toujours comme si ce pouvoir exécutif du Finder dotait n'importe quel usager-admin des droits root en mode indirect (et pas direct, comme les possède root dans sa propre session).
Maintenant, le procédé décrit par quark en passant par la fenêtre d'information du Finder est encore plus troublant. Il suffit, en effet, au diabolique bibi (qui s'en est avisé grâce à quark), d'aller dans le dossier 'Utlisateurs' au répertoire toto et de faire ⌘I dessus (un répertoire, je le rappelle, dont les dossiers sont interdits sauf le 'Public'), de déverrouiller le cadenas (privilège-admin) et de cliquer sur le signe + pour sélectionner dans un liste surgissante son propre nom = bibi, lequel apparaît désormais dans le tableau des Accédants qui possèdent des Privilèges (= permissions). Le diabolique bibi peut, alors que ses permissions ne sont par défaut qu'en lecture seule du répertoire global de toto, les virer en lecture/écriture, puis, en cliquant sur l'engrenage, choisir d'appliquer cette modification aux éléments inclus (ce qui revient à 'propager les permissions' aux éléments contenus dans le répertoire de l'innocent toto).
Lorsque le diabolique bibi revient en mode graphique au répertoire de toto dans le dossier 'Utilisateurs', en l'ouvrant, si les dossiers ( Desktop etc.) portent toujours le signe interdit, cette signalétique est obsolète, car bibi peut sans effort ouvrir chaque dossier prétendument interdit de toto. S'il demande les informations dans une fenêtre du Finder, effectivement il est devenu, à l'égal de toto, habilité en lecture/écriture sur ces dossiers. Et, évidemment, il peut redoubler la mise, en demandant derechef une propagation de ces permissions lecture-écriture aux éléments sub-inclus de chaque dossier. Ce procédé en cascade permet donc à bibi de régresser en lecture/écriture jusqu'à l'échelle élémentaire des contenus du répertoire de toto.
Il est clair que cette extension des droits d'accès permis par le Finder dans sa fenêtre d'information relève des ACL ('Access Control List' = liste des contrôle d'accès), c'est-à-dire une dimension de droits spéciaux introduits pour des raisons de flexibilité dans l'espace multi-utilisateurs qui ont la capacité d'outrepasser les droits standards tels que définis par le protocole POSIX. Ainsi donc le diabolique bibi s'est avisé qu'il peut s'arroger un ACE ('Access Control Entry' = entrée de contrôle d'accès) sur le répertoire de toto en outrepassement des droits de POSIX.
Je propose d'appeler, en l'honneur de quark (dont le pseudo sonne magnifiquement pour cet emploi digne de la Physique) : «Paradoxe de Quark» la contradiction à la règle de droit Posix introduite par le Finder, qui permet par le privilège de ses fonctions exécutives (de copie, de collage, d'information) d'introduire des exceptions qui équivalent à des brèches de confidentialité dans l'usage graphique à l'intérieur de l'espace OS X. Le Paradoxe_de_Quark renvoie à l'état de légende le prétendu cloisonnement de comptes dans l'espace OS X, ce en mode purement graphique (donc sans du tout passer par la ligne de commande) et sans non plus faire appel aux privilèges de Super-Administrateur_Système de root tel qu'ils peuvent s'exercer dans une session root. Le Paradoxe_de_Quark montre que le Finder, dans son pouvoir exécutif, à la fois obéit aux règles de droit POSIX et transgresse les règles de droit POSIX. Il permet à un seul et même usager (le diabolique bibi) d'avoir à la fois en mode graphique des privilèges admin et des privilèges root sans s'être loggé en root.
[Édit. Le Paradoxe_de_Quark revient à dire qu'il n'y a pas de solution purement juridique aux problèmes moraux, ou, en d'autres termes, que le droit ne peut pas remplacer la morale.]
D'abord, permets-moi de te dire : Bravo!
pour l'ingénieuse double solution que tu as exposée à Orbethak et qui lui a permis sans difficulté de récupérer les dossiers importants de sa session bloquée. Est-ce que tu me permets, à présent, de généraliser à partir de cet exemple? Comme je ne voudrais pas que cet exercice (un de mes favoris
) te soustraie le mérite d'«inventeur» dans l'espace de ce fil, je te propose plaisamment de parler à ce sujet de : «Paradoxe_de_Quark».♤
Comme on le sait, l'accès à chaque item dans OS X est réglé par des droits, lesquels définissent d'une part des Accédants et d'autre part des Permissions. Les Accédants se distribuent en 3 catégories : le Propriétaire (u = user), le Groupe (g = group) et les Autres (o = others) ; les Permissions se distribuent également en 3 sortes : Lire (r = read), Écrire (w = write) et Exécuter (x = execute). Par voie de conséquence, chaque item (fichier, dossier, application...) se voit associer des droits d'accès, qui sont ses attributs invisibles, déterminant qui a la permission de quoi regardant l'item.
Ce système s'applique à ces items que sont les répertoires d'utilisateurs et les sous-dossiers qu'ils contiennent. Permets-moi d'appeler toto le nom du répertoire d'un usager-admin dont la session n'est pas actuellement ouverte et bibi le nom du répertoire de l'usager-admin dont la session est actuellement ouverte. Si bibi va fouiner dans le dossier 'Utilisateurs', il tombe sur 2 répertoires : bibi (le sien) présenté graphiquement sous forme d'icône de petite maison blanche, et toto (l'autre) présenté sous forme de simple dossier.
Pour bibi, le répertoire bibi, s'il en lit les droits dans une fenêtre d'information du Finder, a les attributs suivants : bibi = lecture/écriture, groupe = lecture, autres = lecture. En ce qui concerne le répertoire de toto, la fenêtre d'information du Finder donne quelque chose de symétrique : toto = lecture/écriture ; groupe = lecture, autres = lecture. Comme bibi fait partie du groupe qui a des droits de lecture sur le répertoire de toto (le groupe : staff), bibi peut donc ouvrir le répertoire toto et browser son contenu.
♧
Le contenu du répertoire toto pour bibi apparaît sous forme de dossiers (Desktop, Documents, Downloads, Library, Movies, Music, Pictures, Public) qui portent tous un sens interdit à part 'Public'). La fenêtre d'informations du Finder explique que seul toto a des permissions de lecture/écriture sur chacun des dossiers interdits, tandis qu'aucun groupe n'est référencé avec aucune permission, et que les 'autres' sont référencés aussi avec un accès personnalisé qui est égal à zéro. C'est la façon standard dont un répertoire d'usager qui n'est pas celui dont la session est ouverte se trouve protégé en terme de ''privacy' (confidentialité) par le protocole UNIX basique qui est POSIX et qu'OS X utilise comme standard.
Déjà cette situation en défrise plus d'un, parce que si les dossiers d'utilisateurs contenant les données personnelles sont protégés contre l'intrusion, l'espace du répertoire global d'utilisateur lui ne l'est pas (puisque bibi peut browser l'espace du répertoire de toto). On peut justifier cette perméabilité du répertoire global d'usager, par le fait qu'elle permet seule la présence d'un dossier 'Public' sur lequel, si toto a les permissions de lecture/écriture, le groupe (staff) ainsi que les autres ont des permissions de lecture. Cela permet à toto de proposer en consultation des documents à d'autres usagers quand la session de ces derniers sera ouverte, sans néanmoins que ces derniers puissent écrire dans l'espace du dossier 'Public' de toto.
À l'époque où d'innombrables personnes privées proposent en lecture publique une sorte de 'mise-en-scène' d'eux-mêmes (sur Facebook etc.), il n'y a rien de choquant à ce que, dans l'espace multi-utilisateurs d'un ordinateur, le répertoire d'usager de chacun soit ouvert en accès afin de permettre l'existence d'un dossier 'Public' offert en lecture à d'autres.
♡
Là où on peut, néanmoins, déceler une 1ère faille de sécurité concernant la confidentialité des données personnelles d'un répertoire d'usager, c'est que le diabolique bibi (qui n'est pas né de la dernière pluie) s'est avisé qu'il peut utiliser le Finder pour demander une copie du répertoire global de toto (ou d'un de ses dossiers interdits) dans l'espace extérieur à ce répertoire (son propre répertoire, l'espace système, une partition, un DDE, tout ce que l'on voudra). Une fois effectuée, cette copie du répertoire (ou d'un dossier du répertoire) de toto est en lecture/écriture pour le diabolique bibi, car ce dernier étant l'auteur de la copie, il est donc devenu le propriétaire du dossier.
Par voie de conséquence, bibi peut lire le contenu de tous les dossiers qui sont interdits d'accès aussi longtemps qu'ils font partie du répertoire de toto. Il peut aussi les éditer (!), puisqu'il possède les droits d'écriture dessus, soit en modifiant leur contenu, soit en l'effaçant. Cela fait, le diabolique bibi peut très bien re-déplacer dans l'espace du répertoire 'Utilisateurs' le dossier toto qu'il a édité, et le Finder va se borner à demander si bibi veut remplacer le répertoire de toto par le nouveau du même nom. Si le diabolique bibi répond : oui, il peut ainsi, en renseignant un mot-de-passe admin, substituer au répertoire d'usager original toto un répertoire de sa propre fabrication, éventuellement vide.
Il y a là, manifestement, une grave faille de sécurité à l'égard de la confidentialité des répertoires d'usager dans OS X. Ce, parce que le Finder se voit attribuer des droits d'exécution (comme la copie et le collage dans mon exemple) qui équivalent à une véritable traversée des droits POSIX. C'est comme si, en mode indirect, le Finder donnait au diabolique bibi (qui s'en est avisé dans sa grande perversité) des permissions de lecture-écriture sur les contenus du répertoire d'usager de l'innocent toto. C'est toujours comme si ce pouvoir exécutif du Finder dotait n'importe quel usager-admin des droits root en mode indirect (et pas direct, comme les possède root dans sa propre session).
♢
Maintenant, le procédé décrit par quark en passant par la fenêtre d'information du Finder est encore plus troublant. Il suffit, en effet, au diabolique bibi (qui s'en est avisé grâce à quark
), d'aller dans le dossier 'Utlisateurs' au répertoire toto et de faire ⌘I dessus (un répertoire, je le rappelle, dont les dossiers sont interdits sauf le 'Public'), de déverrouiller le cadenas (privilège-admin) et de cliquer sur le signe + pour sélectionner dans un liste surgissante son propre nom = bibi, lequel apparaît désormais dans le tableau des Accédants qui possèdent des Privilèges (= permissions). Le diabolique bibi peut, alors que ses permissions ne sont par défaut qu'en lecture seule du répertoire global de toto, les virer en lecture/écriture, puis, en cliquant sur l'engrenage, choisir d'appliquer cette modification aux éléments inclus (ce qui revient à 'propager les permissions' aux éléments contenus dans le répertoire de l'innocent toto).Lorsque le diabolique bibi revient en mode graphique au répertoire de toto dans le dossier 'Utilisateurs', en l'ouvrant, si les dossiers ( Desktop etc.) portent toujours le signe interdit, cette signalétique est obsolète, car bibi peut sans effort ouvrir chaque dossier prétendument interdit de toto. S'il demande les informations dans une fenêtre du Finder, effectivement il est devenu, à l'égal de toto, habilité en lecture/écriture sur ces dossiers. Et, évidemment, il peut redoubler la mise, en demandant derechef une propagation de ces permissions lecture-écriture aux éléments sub-inclus de chaque dossier. Ce procédé en cascade permet donc à bibi de régresser en lecture/écriture jusqu'à l'échelle élémentaire des contenus du répertoire de toto.
Il est clair que cette extension des droits d'accès permis par le Finder dans sa fenêtre d'information relève des ACL ('Access Control List' = liste des contrôle d'accès), c'est-à-dire une dimension de droits spéciaux introduits pour des raisons de flexibilité dans l'espace multi-utilisateurs qui ont la capacité d'outrepasser les droits standards tels que définis par le protocole POSIX. Ainsi donc le diabolique bibi s'est avisé qu'il peut s'arroger un ACE ('Access Control Entry' = entrée de contrôle d'accès) sur le répertoire de toto en outrepassement des droits de POSIX.
♘
Je propose d'appeler, en l'honneur de quark (dont le pseudo sonne magnifiquement pour cet emploi digne de la Physique
) : «Paradoxe de Quark» la contradiction à la règle de droit Posix introduite par le Finder, qui permet par le privilège de ses fonctions exécutives (de copie, de collage, d'information) d'introduire des exceptions qui équivalent à des brèches de confidentialité dans l'usage graphique à l'intérieur de l'espace OS X. Le Paradoxe_de_Quark renvoie à l'état de légende le prétendu cloisonnement de comptes dans l'espace OS X, ce en mode purement graphique (donc sans du tout passer par la ligne de commande) et sans non plus faire appel aux privilèges de Super-Administrateur_Système de root tel qu'ils peuvent s'exercer dans une session root. Le Paradoxe_de_Quark montre que le Finder, dans son pouvoir exécutif, à la fois obéit aux règles de droit POSIX et transgresse les règles de droit POSIX. Il permet à un seul et même usager (le diabolique bibi) d'avoir à la fois en mode graphique des privilèges admin et des privilèges root sans s'être loggé en root.[Édit. Le Paradoxe_de_Quark revient à dire qu'il n'y a pas de solution purement juridique aux problèmes moraux, ou, en d'autres termes, que le droit ne peut pas remplacer la morale.]
♔
Dernière édition par un modérateur:
Tu aurais eu un clone usb ou fire-wire :
1/ Tes précieuses données étaient en double dans le clone
2/ Tu pouvais démarrer sur le clone et aller voir dans ton Mac ce qui cafouillait dans ta session
3/ Tu étais paré pour l'avenir : ton Mac a 6 ans, et les hypothèses qu'edd72 et moi sont peut-être fausses = ton Mac est peut-être en train d'agoniser.
Q
quark67
Invité
Sujets similaires
10.13 High Sierra
Ma session sur MacBook Retina 12 ne s'ouvre plus! ça bloque
