«Chown user: user lost + found» est-il dangereux?

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.xmlpour 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+foundré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?

— PerlDuck
source

Tous les systèmes de fichiers n'ont pas de répertoire perdu + trouvé. Ext4 le fait, XFS non, par exemple.

— jornane

Pas une réponse, mais vous pouvez simplement créer un script ou un alias pour find (de préférence avec un nom différent) qui commence par un 2>/dev/nullqui 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.

— Joe

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+foundproprié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+foundne pas appartenir à pduck.

* sauf situations exotiques comme pduck suing pour rooter et exécuter une application X. Mais si pduck peut utiliser sudoou alors sunous ne parlons de rien car pduck peut carrément briser la sécurité du système.

— Joshua
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 findplaindre, à moins que je n'élève les autorisations de la ligne de commande, donc je vous suggère d'utiliser

sudo find ...

et laisser lost+foundtel quel {est / devrait être}.

— sudodus
source

Oui, c'est ce que je pensais, mais OTOH il y a cette mklost+foundcommande 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'utiliser sudodans mon propre $ HOME.

— PerlDuck

lost+foundest 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).

— sudodus

N'y place pas de fsckfichiers lorsqu'il rencontre des fichiers "perdus"? L'idée est qu'il fscky a déjà un endroit pour mettre les fichiers (au lieu d'en créer d'abord un). Notez qu'il lost+foundoccupe plus d'espace (16384 octets) qu'un répertoire vide ordinaire (4096 octets).

— PerlDuck

Oui, au moins c'était le but d'origine (similaire à ce qui était chkdskfait 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'aller lost+found. - Au fait, j'ai un lost+foundrépertoire dans /home, mais pas dans mon répertoire personnel /home/sudodus, donc ça ne me dérange pas là-bas.

— sudodus

Je suis d'accord. Et /homej'en ai un autre l+f(ça ne me dérange pas non plus) car /homeet ce /home/pducksont 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 de l+fmon $ HOME. /// Je supprimerai mes commentaires dans quelques minutes / heures pour éviter cette alerte "discussion prolongée… passer au chat" .

— PerlDuck

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.

— pingouin359
source