¿Alguna recuperación de esto? sudo chmod 600. *


8

ADVERTENCIA : NO EJECUTE EL COMANDO MENCIONADO

Entonces parece que hice algo bastante tonto aquí para decirlo suavemente. Intenté cambiar los permisos de algunos archivos en un directorio con el que todos comenzaron .a leer / escribir solo para sudo / root.

Mi intento de cambiar varios archivos a la vez parece haber hecho algo terriblemente global. Mientras estaba dentro de un directorio (no estaba en el directorio raíz) corrí sudo chmod 600 .*y bueno, estoy publicando esto desde mi teléfono ahora ... Todavía tengo la ventana de terminal abierta en este momento, pero estoy bastante seguro de si la computadora portátil se apaga para dormir estoy completamente hecho. Hilarantemente, eso significa que hay una leve urgencia en esta pregunta.

Ah, y esto parece haber cambiado los permisos casi en todas partes, supongo. Ni siquiera puedo ejecutar los comandos lso cd ... Un intento de cd /home/briano cd ~dar el error bash: cd: /home/brian: Permission Deniedy cualquier intento de un sudocomando solo dicebash: /usr/bin/sudo: Permission Denied

Tengo miedo de reiniciar, no tengo idea si hay alguna recuperación integrada de algo tan tonto, pero pensé que trataría de preguntar aquí antes de empeorar las cosas. Soy un Linux bastante nuevo como mi principal convertidor de SO y he estado abogando por él un poco últimamente, pero ay, este duele un poco. Cualquier idea de cosas para probar sería inmensamente apreciada.

EDITAR: quería proporcionar una aclaración sobre cómo / dónde se ejecutó este comando. Esto se ejecutó desde /.atx $, solo un directorio arbitrario, pero más detalles a continuación.

Mientras estaba conectado como mi nombre de usuario normal brian, tenía un terminal abierto /.atxque contenía tres archivos de solo texto de configuración. Cada nombre de archivo comenzó con un .. Ese directorio / nombre / los archivos no son parte de un paquete común, solo un conjunto arbitrario de configuraciones que estaba moviendo programáticamente. Los archivos contenían información de la cadena de conexión del servidor SQL y solo los querían semi oscurecidos.


Sin descripción que directorio que estaban en, supongo que estaba en el interior /root, no / cuando usted hizo esto (por lo que veo en su pregunta), que significa que su .*pegote capturado /rootpropia carpeta (las .referencias al directorio de trabajo actual), junto con todos los archivos / directorios que comienzan con el punto inicial. No estoy seguro de si hay una manera de cambiarlo desde su sistema, pero probablemente podría arrancar desde un USB en vivo y deshacer las cosas desde allí. Sin embargo, no lo tome como una respuesta al 100%, solo un pensamiento.
Sergiy Kolodyazhnyy

Aprecie los pensamientos y comentarios de cualquier manera y lo considerará dependiendo de cómo van las cosas. Esto es realmente tonto ... Voy a actualizar el texto principal con detalles de dónde ejecuté el comando (parte de por qué estoy tan confundido aquí ya que no parecía peligroso en ese momento)
Brian Jorden


44
Voy a suponer que .*en su comando se expandió para incluir .., el directorio principal del directorio en el que estaba. Si estuviera en, por ejemplo, /home/brianentonces los permisos de /homese habrían establecido en 600 y no tendría permisos para buscar en el /homedirectorio. ¿Puedes ejecutar en tu terminal abiertals -ld /*
Charles Green

2
Puede intentar restaurar el permiso, consulte askubuntu.com/questions/43621/… . Hay varias secuencias de comandos allí, pero publiqué un método usando apt-get desde el modo de recuperación (que prefiero a las secuencias de comandos) también, elige tu opción. Como no puede usar sudo, deberá iniciar el modo de recuperación. wiki.ubuntu.com/RecoveryMode asegúrese de volver a montar / rx (ver wiki)
Panther

Respuestas:


3

Menos mal, la recuperación aquí fue más fluida de lo que esperaba y todo parece estar en muy buena forma nuevamente.

Muchas gracias a @CharlesGreen por una explicación de cómo ese comando extendió un directorio. También gracias a @Panther por la información sobre cómo ingresar al modo de recuperación por un problema algo relacionado. (si ambos quieren volver a compartir sus comentarios como respuestas, los votaré)

Afortunadamente, a diferencia de la publicación vinculada, esto parece haber tenido una solución muy sencilla. Parece que cuando me encontré con el sudo chmod 600 .*comando desde un único directorio en el /que se expandió la .*porción a la verdadera permisos directorio raíz de alterar .de /causar cualquier otro permiso para caerse.

La "solución" para esto fue iniciar en modo de recuperación, volver a montar la unidad como lectura / escritura, ir a la raíz principal ( cd /) y luego chmod +rx .. Después de reiniciar, todo parece volver a la normalidad.

Moraleja de la historia, la ejecución de un comando en .*al menos a veces puede afectar el directorio por encima de la actual. Tenía la intención de afectar solo los archivos que comenzaron con. ... ¡Uy!

Muchas gracias a todos los que comentaron y ayudaron.


1
Probablemente afectó el directorio padre porque ..coincide con .*glob.
Cthulhu

1
Otra razón más para usar un shell más sano. zsh, por ejemplo, no incluye .o ..en la expansión de .*forma predeterminada.
Muru

1

La "solución" para esto fue iniciar en modo de recuperación, volver a montar la unidad como lectura / escritura, ir a la raíz principal (cd /), y luego chmod + rx .. Después de un reinicio, todo parece estar de vuelta a normal.

Solo para que quede claro para los futuros lectores que puedan encontrar esto como la respuesta aceptada, existen preocupaciones con la chmod +xsolución como una solución general. Esta pregunta específica parece haber sido el directorio de inicio de los usuarios, por lo que algunas de las inquietudes a continuación pueden ser bajas, pero si esto se aplicó a un servidor comercial y afectó a múltiples usuarios u otros directorios de datos, no se sugiere la solución.

En el lado positivo , este paso permitiría al usuario recuperar el acceso a los archivos para que puedan copiarse en un medio de copia de seguridad para evitar una mayor pérdida. Y al final del día, ese es el objetivo principal durante cualquier esfuerzo de recuperación de datos.

La mayor preocupación es que los archivos originales podrían haber tenido permisos específicos aplicados que ahora faltan. Algunos programas, específicamente ssh, aplican permisos de archivo para garantizar aún más su seguridad y no funcionarán si el +rwpermiso se establece en su carpeta y archivos.

Otra preocupación es que si esto se aplica en la /carpeta raíz ( ) de forma recursiva, habrá otros archivos que podrían estar abiertos para que cualquiera en el sistema los vea y modifique. En un entorno empresarial en el que el servidor puede contener datos confidenciales (información PCI / financiera o de salud / HIPAA), este acceso podría conducir a resultados y repercusiones de la auditoría.

En un entorno personal / doméstico, esta recuperación es probablemente perfectamente aceptable. Solo tenga en cuenta que algunas cosas pueden romperse silenciosamente o actuar de manera extraña.

En un entorno empresarial, puede usarse esta recuperación para recuperar el acceso a los datos, pero en última instancia, cualquier cambio dramático como este debería resolverse reinstalando el servidor y recuperándose de una copia de seguridad.

( TIENES una copia de seguridad actual, ¿no? ;-) )


1
Se adelantó y votó porque hay algunos consejos / información generalmente útiles aquí. En mi situación particular, tuve la suerte de que los únicos permisos que se modificaron estaban directamente dentro /y no entraban en cascada recursivamente en ningún otro directorio. También vale la pena señalar, esto fue solo en mi computadora portátil personal y aunque podría haber perdido parte del trabajo de un día (todavía no había hecho un gran esfuerzo), habría sido una gran molestia y molestia reinstalar mi "usuario" relacionado aplicaciones. Si hubiera sido un servidor de cualquier tipo, generalmente estaría de acuerdo, menos tiempo y esfuerzo para simplemente limpiar / reconstruir.
Brian Jorden
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.