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?
fuente
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.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 enlost+foundno ser propiedad de pduck.* salvo situaciones exóticas como pudding
sua root y ejecutar una aplicación X. Pero si pduck puede usarsudoosuno estamos hablando de nada porque pduck puede romper la seguridad del sistema directamente.fuente
lost+foundes 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 usey dejar
lost+foundcomo está {es / debería ser}.fuente
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 usarsudoen mi propio $ HOME.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).fsckpone archivos allí cuando encuentra archivos "perdidos"? La idea es quefsckya tiene un lugar para colocar los archivos (en lugar de crear primero uno). Tenga en cuenta quelost+foundocupa más espacio (16384 bytes) que un directorio vacío ordinario (4096 bytes).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 elloslost+found. - Por cierto, tengo unlost+founddirectorio/home, pero no en mi directorio de inicio/home/sudodus, por lo que no me molesta allí./hometengo otrol+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 del+fmi $ HOME. /// Eliminaré mis comentarios en un par de minutos / horas para evitar esa alerta de "discusión extendida ... mover al chat" .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.
fuente