Ejecuté chmod 777de forma recursiva /var/y ya no pude conectarme a través de SSH. Leí que eso chmod 600lo solucionaría. Pude conectarme después de hacerlo, pero fue una mala idea.
¿Hay alguna forma de encontrar los modos predeterminados para las carpetas /var/o cómo solucionar este problema?
Ejecutándose en Debian-Squeeze.
Respuesta1
Este es un error muy común para las personas que utilizan un sistema operativo que carece del concepto de permiso. Muchos
sudo chmod -R 777 /
y tales se han publicado quizás con buenas intenciones, pero también es más o menos el único error del usuario que podría hacerme recomendar "simplemente reinstalar" para un sistema *nix.
Si simplemente chmod -R 755, entre otras cosas, le darás lectura yejecuciónpermiso a cada archivo para cualquier persona. Si uno simplemente elimina la ejecución de cada archivo (los directorios necesitan que sea navegable), entonces eliminará el bit de ejecución de algunos archivos que no estaban disponibles.supuestoser ejecutable, etc.
En este caso quizás no sea tan grave como -R /, pero en, por ejemplo, /var/loghay muchos archivos que estánnoSe supone que tiene permisos de lectura para cualquiera. Un pequeño extracto:
-rw-r--r-- alternatives.log
drwxr-x--- apache2
drwxr-xr-x apt
-rw-r--r-- aptitude
-rw-r----- auth.log
-rw-r----- boot
-rw-rw---- btmp
drwxr-xr-x ConsoleKit
drwxr-xr-x cups
-rw-r----- daemon.log
drwxr-xr-x dbconfig-common
-rw-r----- debug
-rw-r----- dmesg
-rw-r--r-- dpkg.log
-rw-r--r-- duplicity-backup.0
drwxr-s--- exim4
-rw-r----- fail2ban.log
-rw-r--r-- faillog
-rw-r--r-- fontconfig.log
drwxr-xr-x fsck
drwxr-xr-x hp
drwxr-xr-x installer
-rw-r----- kern.log
-rw-rw-r-- lastlog
-rw-r--r-- lpr.log
-rw-r--r-- mail.err
-rw-r--r-- mail.info
-rw-r--r-- mail.log
-rw-r--r-- mail.warn
-rw-r----- messages
drwxr-x--- mrtg
drwxr-s--- mysql
-rw-r----- mysql.err
-rw-r----- mysql.log
drwxr-sr-x news
-rw-r--r-- popularity-contest
-rw-r--r-- pycentral.log
-rw-r--r-- rssdler.log
drwxr-xr-x samba
-rw-r----- shorewall-init.log
-rw-r----- syslog
drwxr-xr-x unattended-upgrades
-rw-r----- user.log
-rw-rw-r-- wtmp
-rw-r--r-- Xorg.0.log
Esto no es trivial de restaurar. Y ese era sólo un directorio.
Considerándolo todo: incluso si logró que SSH volviera a funcionar, ha tenido una pérdida de información de permisos que no es trivialmente reparable. Si se trata de un servidor estrictamente personal, las consecuencias probablemente no sean tan nefastas, pero los permisos están establecidos lo más restrictivos posible por una razón. En, por ejemplo, los archivos de registro que mencioné anteriormente, se puede almacenar información confidencial, y ahora es suficiente con un exploit que otorga derechos de usuario regular para descubrir esto y obtener aún más información para ataques de permiso de root.
La última vez que vi a alguien dar el "¡¡¡Hazlo chmod -R 777!!!" consejo ayer en un foro local. ¡No confíes en Internet! :-)