¿Es `chown user: user lost + found` es dañino?

Recientemente creé un sistema de archivos encriptado ( crypto_LUKS) que sirve como $ HOME para un solo usuario en particular (es decir, lo monte como /home/pduck). También agregué una entrada apropiada /etc/security/pam_mount.conf.xmlpara que la partición se desencripte y monte automáticamente cuando el usuario inicie sesión (y se desmonte cuando cierre la sesión). Funciona genial.

Debido a que $ HOME es un sistema de archivos en sí mismo, el usuario tiene un lost+founddirectorio propiedad de root: root. Sé que eliminar el directorio es una mala idea, pero muchos comandos (por ejemplo find) se quejan de no tener acceso. Eso me molesta

Por curiosidad, eliminé el directorio y lo recreé con mklost+found(sin sudo). Ahora el directorio es propiedad de pduck: pduck. ¿Está bien o es crucial que el directorio sea propiedad de root: root?

— PerlDuck
fuente

No todos los sistemas de archivos tienen un directorio perdido + encontrado. Ext4 sí, XFS no, por ejemplo.

— jornane

No es una respuesta, pero podría crear un script o un alias para buscar (preferiblemente con un nombre diferente) que comience con un 2>/dev/nullsilencio de esos mensajes de error. Si lo pones al principio, no interferirá con los argumentos que quieras pasar para encontrar en cada invocación.

— Joe

Respuestas:

Los buenos consejos tienen una justificación para que pueda saber cuándo se convierten en malos consejos.

El propósito de lost+foundser propiedad de root es que, sin importar de quién sea el archivo que se perdió, no se exponga repentinamente a todos. Sin embargo, en este caso, no debería haber un solo archivo en todo el sistema de archivos * que no sea propiedad de pduck; por lo tanto, no hay inconveniente en lost+foundno ser propiedad de pduck.

* salvo situaciones exóticas como pudding sua root y ejecutar una aplicación X. Pero si pduck puede usar sudoo suno estamos hablando de nada porque pduck puede romper la seguridad del sistema directamente.

— Joshua
fuente

lost+found es un directorio del sistema, y evito alterar la propiedad y los permisos de los directorios y archivos del sistema.

Hay otros directorios (y archivos) que hacen findquejas, a menos que eleve los permisos de la línea de comandos, por lo que sugiero que use

sudo find ...

y dejar lost+foundcomo está {es / debería ser}.

— sudodus
fuente

Sí, eso pensé yo, pero OTOH existe ese mklost+foundcomando para crearlo y lo crea con mi propiedad. Tal vez es solo un comando horriblemente escrito que no busca $UID!=0;-) Además, no me gusta la idea de ser forzado (más o menos) a usar sudoen mi propio $ HOME.

— PerlDuck

lost+foundes muy antiguo, creo que desde los primeros días de UNIX, y realmente no sé cuándo se usa hoy en día. Pero creo que es una buena política general para evitar alterar la propiedad y los permisos de los directorios y archivos del sistema (a menos que realmente sepas lo que puede pasar detrás de escena).

— sudodus

¿No fsckpone archivos allí cuando encuentra archivos "perdidos"? La idea es que fsckya tiene un lugar para colocar los archivos (en lugar de crear primero uno). Tenga en cuenta que lost+foundocupa más espacio (16384 bytes) que un directorio vacío ordinario (4096 bytes).

— PerlDuck

Sí, al menos ese era el propósito original (similar a lo que chkdsksucedió con los archivos perdidos en MSDOS), pero rara vez he visto datos en Linux. Tal vez el diario puede restaurar los archivos a donde estaban antes, por lo que no es necesario que vayan a ellos lost+found. - Por cierto, tengo un lost+founddirectorio /home, pero no en mi directorio de inicio /home/sudodus, por lo que no me molesta allí.

— sudodus

Estoy de acuerdo. Y /hometengo otro l+f(tampoco me molesta) porque /homey /home/pduckson particiones separadas en mi máquina. El último está encriptado, el primero no. Sin embargo, cuando me molesta demasiado, puedo montar mi $ HOME en otro lugar y montarlo en mi $ HOME real (como describí aquí , por ejemplo) para deshacerme por completo de l+fmi $ HOME. /// Eliminaré mis comentarios en un par de minutos / horas para evitar esa alerta de "discusión extendida ... mover al chat" .

— PerlDuck

No hay nada realmente mágico sobre el directorio perdido + encontrado. Es solo un directorio simple como cualquier otro y solo se usa para contener archivos / directorios perdidos encontrados durante un fsck después de un bloqueo del sistema o corrupción del sistema de archivos.

Se crea durante mkfs cuando se crea el sistema de archivos y normalmente está vacío. La única razón para los permisos predeterminados es evitar que los archivos confidenciales sean visibles para los usuarios normales si se encuentran y se recuperan durante un fsck. En la era moderna, es raro ver que los archivos se pierdan y se coloquen en esa carpeta.

Si se elimina, creo que fsck lo recreará según sea necesario si resulta que hay archivos que deben colocarse allí. Dado que este es un sistema de archivos para un usuario y sus datos solo, sin necesidad de mantener los datos ocultos de miradas indiscretas, no veo ninguna razón por la que los permisos no puedan cambiarse a, digamos, 755 para evitar que Find se queje o cambie propiedad. Es posible que fsck restablezca sus permisos durante un proceso de recuperación, pero ese es un evento raro en un sistema de archivos moderno a menos que haya una falla grave del hardware.

En cuanto a solo eliminarlo, creo que toda la paranoia en torno a eso se basa en el hecho de que es mejor hacer que fsck haga lo menos posible para recuperar datos, pero no creo que realmente importe mucho en la práctica.

— pingüino359
fuente