"Chown -R root /" ¿cómo estoy jodido?

Accidentalmente ejecuté el comando chown -R root / al intentar cambiar los permisos a la carpeta pública de mi aplicación rails. Creí que esto cambió los permisos a todas mis carpetas en el directorio /. Entonces mi pregunta es, ¿qué tan peligroso es esto? De hecho, la mejor pregunta sería, ¿hay alguna forma de deshacer esto?

Una forma de mitigar el problema aquí (no resolver, pero ayudarlo a salir de un agujero) es ejecutar un proceso en un sistema similar para recopilar las propiedades apropiadas para los archivos. Aprecio que las posibilidades de una coincidencia exacta sean algo escasas, pero si ambas o / s están al mismo nivel con paquetes similares instalados, es posible que tenga suerte.

Una vez que haya recopilado los permisos de archivo en un archivo, puede ejecutar un proceso en su propio sistema para leer los archivos y permisos / propiedades del archivo bueno y reemplazarlos en el suyo. Tengo un par de pequeñas aplicaciones locales en Linux que hacen exactamente esto.

P.ej

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 * otras cosas * directorio * nombre de archivo

En primer lugar, detenga el comando si aún se está ejecutando.

Ahora todo pertenecerá a root y eso es bastante problemático.

Debe intentar restaurar la información de su última copia de seguridad.

También es importante no reiniciar el sistema antes de verificar todas las aplicaciones que se ejecutan y que el usuario las inicie en el arranque. Si lo hace, algunos de ellos pueden no iniciarse correctamente debido a problemas de permisos.

Buena suerte.

Muy y no del todo.

"Muy" en el sentido de que si el comando se ha cumplido, su seguridad está jodida. Ahora no sabe qué caminos tienen qué propietarios y a quién se le debe permitir hacer qué.

"No del todo" en el sentido: ¿estás seguro de que eras root cuando lo hiciste y el comando pasó hasta el final? Si lo cancelaste, tan pronto como lo viste, entonces podrías tener suerte y la reparación podría ser baja. Si no fue root, este comando no debería haber sido capaz de hacerlo, a menos que haya hecho algo así sudo ....

No hay un remedio único para esto. Si tiene una copia de seguridad, puede restaurarla. Es posible que deba verificar las propiedades en la copia de seguridad y aplicarlas. Si ha estado utilizando un verificador de rootkit (por ejemplo, rkhunter), es posible que tenga una lista de las propiedades más básicas y posiblemente pueda solucionarlo. (No es muy probable).

Al menos en Fedora, el comando RPM tiene las opciones --setpermsy --setugids, al usarlas, puede reparar la mayoría de los archivos propiedad del sistema rpm --setugids -a. Para (un poco) arreglar los archivos para cada usuario, puede hacer para cada uno chown -R user /home/user. Probablemente habrá restos que no hayan sido arreglados por lo anterior, particularmente si tiene algún tipo de servidor (web, ftp, otros), esos deberán ser manejados uno por uno.

Probablemente otras distribuciones tienen mecanismos similares. O realice una actualización completa (es decir, instale todo de nuevo, como si estuviera dañado de alguna manera. OK, de alguna manera estaba dañado).

[Sí, esta es una vez más la forma bastante cruel de Unix de enseñar a los usuarios desprevenidos a considerar cada comando cuidadosamente antes de presionar ENTER, y usar la raíz con moderación . Considérate enseñado.]

Si usa Apple OSX, proporciona una función de restauración dentro de las Utilidades de disco para solucionar este mismo problema. Si está utilizando una distribución de Linux, estoy bastante seguro de que tendrá que rehacer todos los permisos manualmente. En cualquier caso, golpea tus manos y no lo vuelvas a hacer.

Desafortunadamente, no conozco ninguna forma de "deshacerlo", pero probablemente pueda dejar los archivos del sistema como propiedad de root y restaurar todos los archivos en su $ HOME para que sean de su propiedad (y haga lo mismo para todos los usuarios de sistema). En ese momento, puede corregir los permisos y / o el propietario de cada archivo que no esté en su directorio $ HOME que lo necesite a medida que surja. Sí, esto es un dolor, pero no creo que haya una solución fácil. Eso es lo que haría de todos modos.

Yo diría que estás bastante "jodido" como dices. La mejor manera (y la más eficiente) es reinstalar y restaurar elementos críticos de sus buenas copias de seguridad. Lo sentimos, esta no es una situación que generalmente tiene una solución rápida con un final feliz. ¡Buena suerte!