"Chown -R root /" comment je suis foudroyé?

J'ai accidentellement exécuté la commande chown -R root / tout en essayant de modifier les permissions sur le dossier public de mon rails. Je croyais que cela a changé les permissions sur tous mes dossiers sur le répertoire /. Donc, ma question est de savoir à quel point cela est dangereux, en fait, la meilleure question serait, est-ce qu'il y a lieu de défaire cela?

Une façon d'atténuer le problème ici (ne pas résoudre, mais vous aider à sortir) est de lancer un processus sur un système similaire pour collecter les propriétés appropriées pour les fichiers. J'apprécie que les chances d'une correspondance exacte soient un peu minces, mais si les deux / s sont au même niveau que les paquets similaires installés, vous pourriez être chanceux.

Une fois que vous avez collecté les autorisations de fichier dans un fichier, vous pouvez ensuite exécuter une procédure sur votre propre système pour lire les fichiers et les perms / propriétaires du bon et les remplacer par le vôtre. J'ai quelques petites applications locales sur Linux qui font exactement 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 chose * répertoire * nom de fichier

Tout d'abord, arrêtez la commande si elle fonctionne encore!

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

Vous devriez essayer de restaurer les informations 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 l'utilisateur qui les lance au démarrage. Si vous le faites, certains d'entre eux peuvent ne pas démarrer correctement en raison de problèmes d'autorisations.

Bonne chance.

Très et pas tout à fait.

"Très" dans le sens que si la commande a effectivement traversé, votre sécurité est vissée. Vous ne savez maintenant quels chemins ont ce que les propriétaires et qui devraient être autorisés à faire quoi.

"Pas tout à fait" dans le sens – Êtes-vous sûr que vous étiez root quand vous l'avez fait et la commande a-t-elle terminé? Si vous l'avez annulé, dès que vous l'avez vu, vous pourriez être chanceux et la réparation peut être faible. Si vous n'étiez pas root, cette commande n'aurait pas pu le faire, sauf si vous avez fait quelque chose comme sudo ...

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

Sur Fedora au moins, la commande RPM a les options --setperms et --setugids , en utilisant ceux que vous pouvez réparer la plupart des fichiers appartenant au système comme rpm --setugids -a . Pour (un peu) réparer les fichiers pour chaque utilisateur, vous pouvez le faire pour chaque 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 une sorte de serveur (web, ftp, autres), ceux-ci devront être traités un par un.

Probablement d'autres distributions ont des mécanismes similaires. Ou faites un rafraîchissement complet (c'est-à-dire, installez tout d'abord, comme si cela avait été endommagé. OK, cela a été endommagé.)

[Oui, c'est encore une fois l'option plutôt cruelle d'Unix d'enseigner aux utilisateurs sans méfiance à considérer chaque commande avec précaution avant d'appuyer sur ENTRÉE et à utiliser avec racine parcimonieuse . Considérez-vous enseigné.]

Si votre OSX Apple utilise une fonction de restauration dans Disk Utilities pour résoudre ce problème. Si vous utilisez une distro linux, je suis certain que vous devrez refaire toutes les autorisations manuellement. Dans les deux cas, frappe vos mains et ne le fais plus

Malheureusement, je ne connais aucun moyen de "défaire", mais vous pouvez probablement laisser les fichiers système appartenant à root et restaurer tous les fichiers dans votre $ HOME pour être la propriété de vous (et faire de même pour tous les utilisateurs de la système). À ce stade, vous pouvez réparer les autorisations et / ou le propriétaire sur chaque fichier qui ne figure pas dans votre répertoire $ HOME qui en a besoin à mesure qu'il se présente. Oui, c'est une douleur, mais je ne pense pas qu'il y ait une solution facile. C'est ce que je ferais de toute façon.

Je dirais que vous êtes assez «vissé» comme vous le dites. La meilleure façon (et la plus efficace) est de réinstaller et de restaurer des é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!