Une récupération de cela? sudo chmod 600. *

8

AVERTISSEMENT - DOIT PAS EXÉCUTER LA COMMANDE MENTIONNÉE

Il semble donc que j'ai fait quelque chose d'assez bête ici pour le dire doucement. J'essayais de modifier les autorisations pour quelques fichiers dans un répertoire qui ont tous commencé avec . pour lire / écrire uniquement pour sudo / root.

Ma tentative de changer plusieurs fichiers à la fois semble avoir fait quelque chose d'assez horriblement global. Alors que je me trouvais dans un répertoire (n'était pas dans le répertoire racine), j'ai lancé sudo chmod 600 .* et je publie ceci depuis mon téléphone ... J'ai toujours la fenêtre du terminal ouverte pour le moment, mais je suis sûr que l'ordinateur portable s'endort, je suis complètement terminé. C'est honteux que cela signifie qu'il y a une urgence à cette question.

Oh, et cela semble avoir changé les permissions à peu près partout où je devine. Je ne peux même pas exécuter les commandes ls ou cd .. . Une tentative de cd /home/brian ou cd ~ donne l'erreur bash: cd: /home/brian: Permission Denied et toute tentative de commande sudo indique simplement bash: /usr/bin/sudo: Permission Denied

J'ai peur du redémarrage, pas la moindre idée s'il y a une récupération intégrée de quelque chose de stupide, mais j'ai pensé que j'essaierais de demander ici avant de rendre les choses pires. Je suis un Linux assez récent car mon système d'exploitation principal l'a converti et le préconisait un peu ces derniers temps, mais aïe, celui-ci pique un peu. Toute idée d'essayer serait grandement appréciée.

MODIFIER: Je voulais apporter des précisions sur la manière dont cette commande a été exécutée. Cela a été exécuté à partir de /.atx $ , juste un répertoire arbitraire, mais plus de détails ci-dessous.

Une fois connecté en tant que nom d'utilisateur régulier brian , un terminal était ouvert à /.atx qui contenait trois fichiers texte de type de configuration uniquement. Chaque nom de fichier a commencé avec un . . Ce répertoire / nom / les fichiers ne font pas partie d'un paquet commun, juste un ensemble arbitraire de configurations que je déplaçais par programme. Les fichiers contenaient des informations sur la chaîne de connexion au serveur SQL et souhaitaient simplement les masquer.

    
posée Brian Jorden 28.10.2017 - 18:54
la source

2 réponses

3

Ouf, la récupération ici était en fait plus douce que ce à quoi je m'attendais et tout semble redevenir en forme.

Merci à @CharlesGreen pour une explication de la façon dont cette commande a été étendue à un répertoire. Merci aussi à @Panther pour plus d'informations sur le mode de récupération pour un problème assez apparenté. (Si vous souhaitez tous les deux partager vos commentaires sous forme de réponses, je les échangerais)

Heureusement, contrairement à la publication liée, cela semble avoir un correctif très simple. Il semble que lorsque j'ai exécuté la commande sudo chmod 600 .* à partir d'un seul répertoire sous / , la portion .* a été étendue au répertoire racine réel, modifiant les autorisations de . from / . / p>

Le "correctif" pour cela consistait à démarrer en mode récupération, à réinstaller le lecteur en lecture / écriture, en allant à la racine principale ( cd / ), puis à chmod +rx . . Après un redémarrage, tout semble redevenir normal.

Morale de l'histoire, l'exécution d'une commande sur .* peut au moins parfois avoir un impact sur le répertoire ci-dessus. J'avais l'intention de n'impacter que les fichiers démarrés avec . ... oops.

Merci à tous ceux qui ont commenté et aidé.

    
réponse donnée Brian Jorden 28.10.2017 - 20:15
la source
1
  

Le "correctif" pour cela consistait à démarrer en mode récupération, à re-monter le lecteur en lecture / écriture, à aller à la racine principale (cd /), puis à chmod + rx. Après un redémarrage, tout revenir à la normale.

Juste pour que tout soit clair pour les futurs lecteurs qui pourraient considérer cela comme la réponse acceptée, la solution chmod +x est une solution générale. Cette question spécifique semble avoir été le répertoire personnel des utilisateurs, de sorte que certaines des préoccupations ci-dessous peuvent être faibles, mais si cela a été appliqué à un serveur d'entreprise et a affecté plusieurs utilisateurs ou autres répertoires de données, la solution n'est pas suggérée.

Du côté positif , cette étape permettrait à l’utilisateur de retrouver l’accès aux fichiers afin de les copier sur un support de sauvegarde pour éviter toute perte supplémentaire. Et au bout du compte, c'est l'objectif principal de tout effort de récupération de données.

La plus grande préoccupation est que les fichiers originaux peuvent avoir des autorisations spécifiques qui sont maintenant manquantes. Certains programmes - en particulier ssh - imposent des autorisations de fichiers pour garantir leur sécurité et ne fonctionneront pas si l'autorisation +rw est définie sur son dossier et ses fichiers.

Une autre préoccupation est que si cela s’applique récursivement au dossier racine ( / ), d’autres fichiers peuvent être ouverts et accessibles à tous les utilisateurs du système. Dans un environnement commercial où le serveur peut contenir des données sensibles (informations PCI / financières ou de soins de santé / HIPAA), cet accès peut entraîner des constatations et des répercussions sur l'audit.

Dans un environnement personnel / domestique, cette récupération est probablement parfaitement acceptable. Notez simplement que certaines choses peuvent être silencieusement brisées ou agir bizarrement.

Dans un environnement professionnel, il est possible d’utiliser cette récupération pour retrouver l’accès aux données, mais en fin de compte, tout changement radical comme celui-ci devrait être résolu en réinstallant le serveur et en récupérant à partir d’une sauvegarde.

( Vous avez une sauvegarde en cours, n'est-ce pas?; -) )

    
réponse donnée dan_linder 03.11.2017 - 14:02
la source

Lire d'autres questions sur les étiquettes