“Chown -R root /” comment je suis foutu?

J'ai accidentellement exécuté la commande chown -R root / en essayant de modifier les autorisations du dossier public de mon application rails. Je croyais que cela changeait les permissions sur tous mes dossiers du répertoire /. Ma question est donc la suivante: à quel point est-ce dangereux? En fait, la meilleure question serait de savoir s'il est possible de l'annuler.

Une façon d’atténuer le problème ici (non pas de résoudre, mais de vous aider à sortir d’un trou) consiste à exécuter un processus sur un système similaire afin de collecter les droits de propriété appropriés pour les fichiers. J'apprécie les chances d'une correspondance exacte sont un peu minces, mais si les deux systèmes sont au même niveau avec des paquets similaires installés, vous pourriez avoir de la chance.

Une fois que vous avez collecté les autorisations de fichier dans un fichier, vous pouvez ensuite exécuter un processus sur votre propre système pour lire les fichiers et les perms / propriétaires du bon et les remplacer sur le vôtre. J'ai quelques petites applications maison sur Linux qui font justement cela.

Par exemple

777*0*0*S*16*1334559119*1334532895*1361208513*/usr/lib32/*libgomp.so.1
644*0*0*F*67370*1359536382*1359374461*1359717843*/usr/lib32/*librt.a
644*0*0*F*59044*1334559119*1334532931*1355405098*/usr/lib32/*libgomp.so.1.0.0
644*0*0*F*1238*1359536382*1359374461*1359717843*/usr/lib32/*libBrokenLocale.a
777*0*0*S*17*1359536382*1359374460*1361208513*/usr/lib32/*libdl.so
644*0*0*F*905712*1334559116*1334533011*1355405098*/usr/lib32/*libstdc++.so.6.0.16
777*0*0*S*15*1333306601*1323929512*1361208513*/usr/lib32/*libbz2.so.1.0
777*0*0*S*24*1359536382*1359374460*1361208513*/usr/lib32/*libnss_files.so
644*0*0*F*1128*1359536382*1359374462*1359717843*/usr/lib32/*crt1.o

RWX * UID * GID * Autre matériel * Répertoire * Nom du fichier

Tout d'abord, arrêtez la commande si elle est toujours en cours d'exécution!

Maintenant tout appartiendra à la racine et c'est tout à fait problématique.

Vous devriez essayer de restaurer les informations à partir de votre dernière sauvegarde.

Il est également important de ne pas redémarrer le système avant de vérifier toutes les applications en cours d'exécution et que l'utilisateur les lance au démarrage. Si vous le faites, certains d'entre eux risquent de ne pas démarrer correctement en raison de problèmes d'autorisations.

Bonne chance.

Très et pas tout à fait.

"Très" en ce sens que si la commande est bien passée, votre sécurité est foutue. Vous ne savez pas maintenant quels chemins ont quels propriétaires et qui devrait être autorisé à faire quoi.

"Pas tout à fait" dans le sens - êtes-vous sûr d'être à la racine lorsque vous l'avez fait et la commande a-t-elle été exécutée jusqu'au bout? Si vous l'avez annulé, dès que vous l'avez vu, vous risquez d'être chanceux et la réparation risque d'être faible. Si vous n'étiez pas root, cette commande n'aurait pas dû être capable de le faire, à moins que vous n'ayez fait quelque chose comme sudo ....

Il n'y a pas de solution unique à cela. Si vous avez une sauvegarde, vous pouvez la restaurer. Vous devrez peut-être vérifier les droits de propriété dans la sauvegarde et les appliquer. Si vous utilisiez un vérificateur de rootkit (disons rkhunter), il pourrait avoir une liste des propriétaires les plus élémentaires et éventuellement pouvoir le réparer. (Pas très probable).

Sur Fedora au moins, la commande RPM a les options --setpermset --setugids, en utilisant celles-ci, vous pouvez réparer la plupart des fichiers appartenant au système, tels que rpm --setugids -a. Pour (un peu) corriger les fichiers pour chaque utilisateur, vous pouvez le faire pour chacun chown -R user /home/user. Il y aura probablement des restes qui n'ont pas été corrigés par ce qui précède, en particulier si vous avez un type de serveur (Web, ftp, autres), ceux-ci devront être traités un par un.

Probablement d'autres distributions ont des mécanismes similaires. Ou effectuez une actualisation complète (c'est-à-dire, installez tout à nouveau, comme s'il avait été endommagé. OK, il a été endommagé d'une manière ou d'une autre.)

[Oui, c’est encore une fois la méthode assez cruelle d’Unix pour apprendre aux utilisateurs peu méfiants à bien considérer chaque commande avant d’appuyer sur ENTREE et à utiliser root avec parcimonie . Considérez-vous comme enseigné.]

Si vous utilisez OSX apple fournit une fonctionnalité de restauration dans Utilitaires de disque pour résoudre ce problème. Si vous utilisez une distribution linux, je suis presque certain que vous devrez rétablir toutes les autorisations manuellement. Dans les deux cas, frappez vos mains et ne recommencez pas

Malheureusement, je ne connais aucun moyen de "l'annuler", mais vous pouvez probablement laisser les fichiers système appartenant à root et restaurer tous les fichiers de votre $ HOME qui vous appartiendront (et faire la même chose pour tous les utilisateurs du système. système). À ce stade, vous pouvez corriger les autorisations et / ou le propriétaire de chaque fichier qui ne se trouve pas dans votre répertoire $ HOME et qui en a besoin à mesure qu'il apparaît. Oui, c'est pénible, mais je ne pense pas qu'il y ait une solution facile. C'est ce que je ferais quand même.

Je dirais que tu es assez "foutu" comme tu le dis. Le meilleur moyen (et le plus efficace) est de réinstaller et de restaurer les éléments critiques à partir de vos bonnes sauvegardes. Désolé, ce n'est pas une situation qui a généralement une solution rapide avec une fin heureuse. Bonne chance!