26

Acabo de ejecutar esto hace unos segundos. Me las arreglé para hacer Ctrl, Ctan pronto como me di cuenta de lo que comencé a hacer.

Hasta ahora, el único directorio por el que comenzó a pasar es /bin.

Tengo miedo de hacer cualquier otra cosa. Hasta ahora me di cuenta de que ya no puedo usarlo sucomo mi usuario normal.

Afortunadamente todavía tengo otra terminal raíz abierta. ¿Qué debo hacer?

— Será
fuente

26

Suena como si te hubieran comido allí, amigo.

— ta.speot.is

44

Ahora comprende la importancia de las copias de seguridad. Hazlo regularmente.

— Juliano

Al menos no chmod desde la raíz. Eso es un desastre total. Al menos rm -rf desde la raíz le da más espacio en el disco y lo prepara para una reinstalación completa del sistema, chmod simplemente deja un desastre real que es bastante difícil de recuperar por cualquier cosa que no sea una reinstalación completa del sistema. La hierba es marrón a ambos lados de la cerca, ¿eh?

— Fiasco Labs

10

La mayoría de todo en / bin / debe ser propiedad de root: root, por lo que si ejecuta lo siguiente, puede corregir la propiedad de esos archivos:

chown root:root -R /bin/

También puede asegurarse de que el bit setuid esté configurado correctamente en / bin / su, lo que puede solucionar con lo siguiente:

chmod 4755 /bin/su

— epic9x
fuente

1

En Ubuntu, es especialmente importante hacer lo mismo con sudo. ¿No creo que una contraseña de root esté configurada por defecto? Por cierto, realmente recomendaría usar sudo en lugar de shells de raíz. El medio segundo que lleva escribir sudo normalmente detiene errores como ese en las pistas. Sólo trabajando en un intérprete de comandos es más fácil de la señorita ...

— Bernd Haug

44

paste.ubuntu.com/362468 es un "ls -l / bin" de mi escritorio Ubuntu 9.10. Si bien es posible que no tenga exactamente los mismos archivos instalados que usted, al menos debería darle una buena pista sobre qué archivos necesitan permisos especiales.

— andol

@Bernd: Aunque no hago mucho trabajo administrativo, me he dado cuenta de que sudo menos cosas tontas que como root. Es posible que nunca vuelva a usar una contraseña de root. (Y, no, no hay una contraseña raíz predeterminada en Ubuntu, y no creo que haya una en MacOSX).

— David Thornley,

@David: Definitivamente no hay una contraseña raíz predeterminada en OS X, y configurar una es principalmente un error, IMO. Casi siempre hay otra forma mejor. El problema es que las Mac no son demasiado seguras para empezar; Espero ver mucha 'diversión' una vez que tengan una base de instalación más grande para que RKs, Virii, clientes de Botnet sean rentables.

— Bernd Haug

36

Usuario de Redhat:

chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids

Usuario de Debian / Ubuntu:

chown 0:0 /bin/*  /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen

Mientras la pantalla se está ejecutando, haga esto al menos dos veces:

dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
    | xargs apt-get install --reinstall --

Presta mucha atención a la salida porque si se queja de que algo tiene los permisos incorrectos, debes arreglarlo en otra ventana de pantalla.

Curso intensivo en pantalla:

Control+A     - command key
Control+A a   - emit a control+A
Control+A n   - next "screen"
Control+A c   - create "screen"

Usuario de Solaris:

Estas jodido

pkgchk -R / -f -a

restablecerá todos los permisos, pero la configuración todavía se romperá. Utilice una copia de seguridad u otra máquina solaris para buscar scripts y archivos setuid / setgid y corregirlos manualmente.

LO IMPORTANTE SOBRE LOS BACKUPS

Es que puedes recuperarlos, no que los tomes.

Otras personas le han dado consejos para realizar copias de seguridad, pero quiero agregar que debe probarlas. Si está utilizando un sistema unixish, no hay razón alguna para que no pueda volcar los archivos en otra máquina periódicamente y asegurarse de que todo funcione.

— geocar
fuente

Usuario de FreeBSD: nunca

— cometería

10

@einstiien Sí, los usuarios de FreeBSD van directamente al rm -rfescenario.

— Grawity

@grawity: jajaja, buena.

— Einstiien

Usuarios pobres de Solaris :(

— Mircea Chirea

3

Tenga en cuenta que las banderas set-uid en cualquier binario afectado también pueden haberse eliminado; Esta es una característica de seguridad de Chown. Verifique con algún otro sistema qué binarios tienen los indicadores set-uid o set-gid y asegúrese de configurarlos también en sus binarios.

— Osito de peluche
fuente

3

Iba a explicar los detalles del uso de RPM para restablecer los permisos de archivos, pero encontré un sitio con mucha más información . También menciona que Ubuntu / Debian (así que .debs en general) no lo admite.

Pero, en general, la opción que busca estaría en la línea:

rpm --setugids {packagename}

— Cooperativas
fuente

Esto está en un sistema ubuntu, como lo indican las etiquetas. Esto significa que se usan dpkg y .DEB en lugar de rpm y .RPM

— Kevin M

2

Si se tratara de un sistema Debian, podría volver a instalar todo.

— ptman
fuente

0

¿tienes una copia de seguridad que funcione? en caso afirmativo, restaure su carpeta bin.

de lo contrario, mire otro cuadro donde instaló la misma versión de ubuntu y chownlo que encuentra en la instalación de trabajo.

— cristiano
fuente

0

intente esto: encuentre todos los datos de www en el directorio / bin

# find /bin -user www-data

luego cambie www-data nuevamente al usuario original

# find /bin -user www-data -exec chown ORiginalUser {} \;

# then change www-data back to oringal group
# find /bin -group www-data -exec chgrp originaluser {} \;

— squillman
fuente

0

Gracias a todos por las excelentes respuestas, todo parece estar arreglado ahora.

/ bin / su funcionó una vez chmod'd a 4755 (no estoy seguro de por qué chown cambió el bit suid)

no me di cuenta, pero también comenzó a funcionar a través del directorio / home, pero fue una solución bastante fácil (solo configure user: group para el usuario para cada directorio)