Récemment, j'ai créé un système de fichiers crypté ( crypto_LUKS
) qui sert de $ HOME à un seul utilisateur particulier (c'est-à-dire que je le monte comme /home/pduck
). J'ai également ajouté une entrée appropriée /etc/security/pam_mount.conf.xml
pour que la partition soit automatiquement déchiffrée et montée lorsque l'utilisateur se connecte (et démontée lorsqu'il se déconnecte). Fonctionne très bien.
Parce que $ HOME est un système de fichiers à part entière, l'utilisateur possède un lost+found
répertoire appartenant à root: root. Je sais que la suppression du répertoire est une mauvaise idée mais de nombreuses commandes (par exemple find
) se plaignent de n'avoir aucun accès. Ça m'ennuie.
Par curiosité, j'ai supprimé le répertoire et l'ai recréé avec mklost+found
(sans sudo
). Maintenant, le répertoire appartient à pduck: pduck. Est-ce correct ou est-il crucial que le répertoire soit la propriété de root: root?
la source
2>/dev/null
qui fait taire ces messages d'erreur. Si vous le mettez au début, cela n'interférera pas avec les arguments que vous souhaitez transmettre pour trouver dans chaque invocation.Réponses:
Les bons conseils sont accompagnés d'une justification pour que vous puissiez savoir quand ils deviennent de mauvais conseils.
Le but de la
lost+found
propriété de root est que, quel que soit le fichier perdu, il ne soit pas soudainement exposé à tout le monde. Cependant, dans ce cas, il ne devrait pas y avoir un seul fichier dans tout le système de fichiers * n'appartenant pas à pduck; il n'y a donc aucun inconvénient àlost+found
ne pas appartenir à pduck.* sauf situations exotiques comme pduck
su
ing pour rooter et exécuter une application X. Mais si pduck peut utilisersudo
ou alorssu
nous ne parlons de rien car pduck peut carrément briser la sécurité du système.la source
lost+found
est un répertoire système, et j'évite d'altérer la propriété et les autorisations des répertoires et fichiers système.Il y a d'autres répertoires (et fichiers) qui font se
find
plaindre, à moins que je n'élève les autorisations de la ligne de commande, donc je vous suggère d'utiliseret laisser
lost+found
tel quel {est / devrait être}.la source
mklost+found
commande pour le créer et il le crée avec ma propriété. Peut-être que c'est juste une commande horriblement écrite qui ne vérifie pas$UID!=0
;-) De plus, je n'aime pas l'idée d'être forcé (plus ou moins) d'utilisersudo
dans mon propre $ HOME.lost+found
est très ancien, je pense depuis les premiers jours UNIX, et je ne sais pas vraiment quand il est utilisé de nos jours. Mais je pense que c'est une bonne politique générale pour éviter de falsifier la propriété et les autorisations des répertoires et fichiers système (à moins que vous ne sachiez vraiment ce qui peut se produire en arrière-plan).fsck
fichiers lorsqu'il rencontre des fichiers "perdus"? L'idée est qu'ilfsck
y a déjà un endroit pour mettre les fichiers (au lieu d'en créer d'abord un). Notez qu'illost+found
occupe plus d'espace (16384 octets) qu'un répertoire vide ordinaire (4096 octets).chkdsk
fait avec les fichiers perdus dans MSDOS), mais j'ai rarement, voire jamais vu de données là-bas sous Linux. Peut-être que la journalisation peut restaurer les fichiers là où ils étaient auparavant, ils n'ont donc pas besoin d'allerlost+found
. - Au fait, j'ai unlost+found
répertoire dans/home
, mais pas dans mon répertoire personnel/home/sudodus
, donc ça ne me dérange pas là-bas./home
j'en ai un autrel+f
(ça ne me dérange pas non plus) car/home
et ce/home/pduck
sont des partitions séparées sur ma machine. Ce dernier est crypté, le premier ne l'est pas. Cependant, quand cela m'énerve trop, je peux monter mon $ HOME ailleurs et le lier à mon $ HOME réel (comme je l'ai décrit ici , par exemple) pour me débarrasser complètement del+f
mon $ HOME. /// Je supprimerai mes commentaires dans quelques minutes / heures pour éviter cette alerte "discussion prolongée… passer au chat" .Il n'y a rien de vraiment magique dans le répertoire lost + found. C'est juste un répertoire ordinaire comme les autres et n'est utilisé que pour conserver les fichiers / répertoires perdus trouvés lors d'un fsck après un crash système ou une corruption du système de fichiers.
Il est créé pendant mkfs lorsque le système de fichiers est créé et est normalement vide. La seule raison des autorisations par défaut est d'éviter que les fichiers sensibles ne deviennent visibles pour les utilisateurs réguliers s'ils sont trouvés et récupérés lors d'un fsck. À l'ère moderne, il est rare de voir des fichiers se perdre et être placés dans ce dossier.
S'il est supprimé, je pense que fsck le recréera au besoin s'il se trouve des fichiers qui doivent y être placés. Puisqu'il s'agit d'un système de fichiers pour un utilisateur et ses données seules sans avoir besoin de garder les données cachées des regards indiscrets, je ne vois aucune raison pour que les autorisations ne puissent pas être changées en, disons, 755 pour empêcher find de se plaindre ou de les changer. la possession. Il est possible que fsck réinitialise ses autorisations lors d'un processus de récupération, mais c'est un événement rare sur un système de fichiers moderne, sauf en cas de défaillance matérielle grave.
En ce qui concerne la suppression, je pense que toute la paranoïa qui se fonde sur le fait qu'il est préférable que fsck fasse le moins possible pour récupérer les données, mais je ne pense pas que cela ait vraiment beaucoup d'importance dans la pratique.
la source