¿Cómo restablecer los permisos de carpeta a sus valores predeterminados en Ubuntu?


19

Recientemente escribí el comando

sudo chmod 777 -R /

después de eso algunas cosas como

sudo -i

No funcionan normalmente. Entonces, me pregunto si hay alguna forma de restablecer los permisos de la carpeta a su estado original.


No creo que Linux recuerde las configuraciones de permisos anteriores. Intente crear un nuevo archivo y observe qué configuración de permisos obtiene.
thecoshman

Oh, espera, veo lo que hiciste allí. Esta es probablemente una situación de reinstalación. Simplemente haga una copia de seguridad de sus datos, tome nota de qué aplicaciones ha instalado. Diviértete, ¿por qué no pruebas 10.4? (nunca mejor nombre por cierto ... qué es esa cosa de radio media?)
thecoshman

Te reto a que encuentres a una persona que no haya hecho exactamente eso: D es una situación muy complicada. puedes arreglarlo, prueba la respuesta de jlovi pero tomará tiempo y esfuerzo y será frustrante. simplemente reinstale y termine de una vez. Y nunca use sudo chmod a menos que sepa lo que está haciendo.
Jack Mayerz

Respuestas:


17

Es posible regresar de esta situación desordenada.

Volví a ejecutar el mismo tipo de problema (algunos errores en un script que estaba escribiendo) y lo resolví, pero debes pedir la ayuda de algún experto. ¡Sé muy cauteloso!

Primero, mi situación fue más fácil de resolver porque tenía un sistema de arranque dual (Ubuntu y mi antigua instalación de Fedora), pero ejecutar el sistema operativo desde un CD / DVD o una llave USB debería hacer lo mismo.

MPOINT=/mount/ubuntu

Primero monté mis sistemas de archivos de esta manera (no olvides crear los puntos de montaje):

mount /dev/ubuntu/root $MPOINT
mount /dev/ubuntu/home $MPOINT/home

Luego ejecuté el siguiente comando (mi problema era solo en unos pocos directorios críticos) para copiar los permisos del sistema en ejecución al desordenado (de hecho, en mi caso, instalé un sistema Ubuntu en Virtual Box bajo fedora y obtuve los permisos allí):

find /etc /usr /bin /sbin -exec stat --format "chmod %a \"${MPOINT}%n\"" {} \; > /tmp/restoreperms.sh

Y luego ejecuté el script restoreperms.sh.

Pude volver a arrancar en Ubuntu.

El contenido de restoreperms.sh será algo así como:

(...)
chmod 755 /mount/ubuntu//etc/ppp
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up
chmod 2750 /mount/ubuntu//etc/ppp/peers
chmod 640 /mount/ubuntu//etc/ppp/peers/provider
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up.d
chmod 777 /mount/ubuntu//etc/ppp/resolv.conf
(...)

No lo probé, pero también debe funcionar para propietarios y grupos de propietarios. Algo como:

find /etc /usr /bin -exec stat --format 'chown %U:%G ${MPOINT}%n' {} \; > /tmp/restoreperms.sh^

(...)
chown root:root /mount/ubuntu//etc/obex-data-server/imaging_capabilities.xml
chown root:root /mount/ubuntu//etc/obex-data-server/capability.xml
chown root:dip /mount/ubuntu//etc/ppp
chown root:root /mount/ubuntu//etc/ppp/ipv6-up
chown root:dip /mount/ubuntu//etc/ppp/peers
chown root:dip /mount/ubuntu//etc/ppp/peers/provider
chown root:root /mount/ubuntu//etc/ppp/ipv6-up.d
chown root:root /mount/ubuntu//etc/ppp/resolv.conf
(...)

Por supuesto, debe tener cuidado aquí, que el UID y el GID son iguales en ambos sistemas, pero para los usuarios y grupos relacionados con el sistema, esto no debería ser un problema.

Editar:

Además, el propietario de la configuración anulará los indicadores SGID y SUID , lo que causa problemas extraños (por ejemplo, no podrá realizar sudo a menos que el permiso sea 4755). Debe y solo debe establecer permisos DESPUÉS de configurar los propietarios. GUARDE la información completa del permiso de archivo junto con la información del propietario.

Rk:

  1. Una cosa importante para esto es mantener un disco de instalación sincronizado con la versión que está utilizando, o al menos trabajar con la versión actual de ubuntu.
  2. Ahora, tengo estos comandos en un cronjob, ejecutándome todos los días (podrían ser semanas) para mantener esa información. Hará la solución más fácil la próxima vez pero, por supuesto, como tengo esto ahora, nunca volverá a suceder. ;-) Algo como esto:

    0 12 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chmod %a %n" {} \; |/bin/bzip2 -c > /tmp/restore_chmod.$(/bin/date +%w).sh.bz2

    0 13 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chown %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_chown.$(/bin/date +%w).sh.bz2

El comando correcto (combinado) es más parecido a:

`/usr/bin/find / -exec /usr/bin/stat --format="[ ! -L {} ] && /bin/chmod %a %n" {} \; -exec /usr/bin/stat --format="/bin/chown -h %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_fileperms.$(/bin/date +%w).sh.bz2`

Tenga en cuenta que es posible que se requiera un cuidado adicional para tener en cuenta los paréntesis en los nombres de archivo (en configuraciones regionales, por ejemplo) y que chown puede desactivar silenciosamente setuid y setgid bits establecidos por chmod. En el último caso, que rompería, digamos, / bin / su y / usr / bin / sudo, es posible que deba cambiar el orden de las cláusulas ejecutivas anteriores.


Solo una excelente respuesta. Lo señalé en Ask Ubuntu
Private

¡Solo una solución perfecta para mí!

2

Después de recuperar sudo o seleccionar el modo de recuperación en el arranque

Es posible recuperar un sistema completo utilizando debsums que verifican la integridad y los permisos del archivo.

de la página del manual:

apt-get install --reinstall $(dpkg -S $(debsums -c) | cut -d : -f 1 | sort -u)

Reinstala paquetes con archivos modificados

o limitado a una ruta específica, por ejemplo /usr:

apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/usr ) | cut -d : -f 1 | sort -u)

o limitado a un conjunto múltiple de ruta, por ejemplo: /sbin /etc /var

apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/etc -e ^/sbin -e ^/var  ) | cut -d : -f 1 | sort -u)

Cómo debsums realmente comprueba los permisos? Traté chmod a-x /bin/pingy debsums -cno informaría ese archivo.
reox

0

Siempre mira lo que corres como sudo.

Este hilo explica que puede volver a configurar manualmente algunos permisos, y un script allí ayuda con esto, pero aún así es un gran trabajo. En su lugar, siga los consejos en la banda de rodadura para guardar sus paquetes instalados (marcas) y reinstalar el sistema operativo, y aplicar sus marcas de paquetes guardados para recuperar sus aplicaciones.


0

Hasta donde yo sé, solo los paquetes del Sistema V y los RPM ofrecen un comando para reparar los permisos de los archivos. En el Sistema V (Solaris) es pkgchk, con RPM es rpm --setperms.

Desafortunadamente, no parece existir tal comando para los paquetes Debian / Ubuntu, pero podría estar equivocado aquí.

Pero incluso con la ayuda de estos comandos, no es una tarea trivial volver a poner su sistema en un estado sano, y al repararlo, puede causar nuevos daños fácilmente, si no tiene cuidado.

Aparte de lo que dijo Joseph, no eres el primero, y no serás el último en ingresar dicho comando. Pero la idea sola, cambiar los permisos de archivos a 777 en un sistema Unix, es una fuerte indicación de que no tienes mucha experiencia con este tipo de sistema. Lo mejor que puede hacer en esta situación es hacer una copia de seguridad de lo que necesitará nuevamente (directorios de inicio, archivos de configuración, archivos de correo) e intentar una instalación nueva.

Y debe tener mucho, mucho cuidado cuando restaure sus archivos de copia de seguridad dañados.

¡Buena suerte!

PD: ¿Me pregunto qué tipo de problema querías resolver?


0

Wow, lo mataste. ¡Está muerto! Intente iniciar sesión y usar la máquina como root (ya que la activó), luego cambie la pertenencia al grupo de root a los usuarios. Esto puede o no funcionar porque nunca lo he probado antes, pero vale la pena intentarlo.


0

No puedes deshacer una chmodoperación; al menos no en el sentido de retroceder a una configuración anterior, que es lo que requiere esta situación. Podría decirse que puede deshacer una chmodoperación chmoddevolviendo cada archivo y directorio a su modo original, pero no todos son iguales; determinar los modos originales es complicado (como se discutió en las otras respuestas).

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.