Une chose a mal tourné :l'utilisation de sudo avec cette commande. Le -R le commutateur indique chmod pour définir de manière récursive les autorisations sur ce répertoire, ce qui est, dans tous les cas, une action non recommandée (devrions-nous l'appeler :hérésie) si vous ne savez pas ce que vous faites (une fois que cela m'est arrivé, je n'ai pas lancez la commande, mais une interface graphique défectueuse l'a créée et mon système est devenu câblé).
Ce n'était que des autorisations de fichiers. Alors pourquoi tout le système semble-t-il complètement explosé ?
GNU/Linux est très sensible aux autorisations de fichiers, car il a été construit avec stabilité et sécurité à l'esprit. Il en va de même pour la plupart des programmes exécutés sous GNU/Linux (c'est-à-dire apache2 abandonne les privilèges root et utilise www-data , ou un utilisateur similaire, et votre 700 l'autorisation ne lui permettrait pas de lire/écrire ses propres fichiers).
Pourquoi est-ce qu'aucun mot de passe de connexion ne fonctionne maintenant ?
Comme vous l'avez déjà mentionné, les mots de passe de connexion sont stockés dans un fichier en /etc/passwd et seul root (je suppose que vous n'avez pas changé cela) peut le lire, mais l'invite de connexion (ou la connexion à l'interface graphique) utilise un compte sans privilège, il ne peut donc pas lire le fichier.
Mais comment la modification des autorisations a-t-elle tout compromis ?
Comme indiqué ci-dessus, Linux est très sensible aux autorisations de fichiers. Certains programmes vérifient même les autorisations de leurs fichiers de configuration et s'ils ne sont pas attendus, ils ne fonctionneront pas du tout.
Comment puis-je restaurer mon répertoire etc à son état antérieur ?
Si vous utilisez une distribution basée sur RPM, cela peut être fait en utilisant le rpm --setperms commande, ce serait douloureusement revenir un par un les paquets, sur le système de type Debian apt-get --reinstall install est votre ami. D'autres solutions peuvent être disponibles, mais elles nécessitent un système fonctionnel.
Voyons, ce que vous avez fait est de définir des autorisations dans l'ensemble du répertoire /etc comme lecture/écriture/exécution autorisées uniquement pour le propriétaire du fichier/répertoire, refusées pour tout le monde. Si vous êtes confus par les autorisations de fichiers, vous pouvez en savoir plus sur Wikipedia :autorisations UNIX traditionnelles.
La raison pour laquelle vous avez fait exploser votre système est que de nombreux processus ne peuvent plus lire leurs paramètres, ne pouvant plus accéder à /etc. Il ne sera pas facile de restaurer l'intégralité du répertoire /etc à son état précédent. La façon de procéder dépendra de votre distribution, mais en gros, cela signifie réinstaller chaque paquet contenant un fichier dans /etc.
En tant que pansement rapide pour pouvoir utiliser le système, afin de le réparer correctement (réinstaller tous les packages avec le contenu dans /etc, comme indiqué ci-dessus), vous pouvez faire :
# sudo find /etc -type d -exec chmod 775 '{}' \;
# sudo find /etc -type f -exec chmod 664 '{}' \;
Avec ces deux lignes, vous définirez des autorisations libérales dans tous les répertoires /etc, avec la lecture/écriture autorisée pour le propriétaire et le groupe, et la lecture autorisée pour tous les autres. La raison des deux chmod est de définir le bit d'exécution uniquement sur les répertoires. Certains processus se plaindront ou échoueront malgré tout, y compris tout exécutable dans /etc, mais vous devriez pouvoir effectuer la réinstallation que j'ai décrite ci-dessus.
Veuillez noter que jusqu'à ce que vous récupériez les autorisations d'origine, votre système sera, à tout le moins, dans un état non sécurisé.