Forum Linux.général locate et home chiffré

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
10
mar.
2018

Bonjour,

Mon home est chiffré et je m'aperçois que locate ne trouve rien si je l'utilise pour chercher un fichier dans mon home. locate fonctionne bien car il trouve ailleurs sauf dans mon home. J'ai consulté le fichier /etc/updatedb.conf et je vois /home/.ecryptfs dans PRUNEPATHS, il est donc normal que locate ne trouve rien dans mon home.
Ma question est donc : est-ce juste une question de non divulgation d'information à un utilisateur non autorisé (tous les utilisateurs de la machine attaquant la même BD en utilisant locate, le contenu de chaque home non chiffré est visible avec locate) ou bien y-a-t-il une raison encore plus impérative de bloquer locate sur un home chiffré ?

Sinon find marche très bien mais j'ai toujours du mal à en mémoriser la syntaxe, d'où locate.

  • # Précaution

    Posté par  . Évalué à 2.

    Ce doit être effectivement par précaution, on pourrait aussi imaginer que la db de locate soit sur une partition non chiffrée.

    À toi de l’active si tu le souhaites du coup.

    Si tu as un SSD tu peux te dispenser de locate et plutôt utiliser find.

    • [^] # Re: Précaution

      Posté par  . Évalué à 2.

      Sinon, sans compromis: il peut utiliser l'option -U, --database-root PATH de updatedb (ainsi que -d, --database DBPATH de locate, bien sûr) pour mettre la base de données dans son $HOME, ce qui à mon humble avis est nettement plus propre que de mettre un truc relatif à des données utilisateur dans une partition système.
      Accessoirement, s'il mets ça dans ses fichiers utilisateurs, le mécanisme sera portable et plus performant:

      • plus performant parce que pour un disque mécanique il y aura moins de déplacements des têtes de lecture;
      • plus performant parce que j'ose imaginer que locate ne charge pas tous les fichiers quand ils sont segmentés (et, pour le coup, ça serait bien une segmentation par «zones», on peut espérer que locate n'ira pas chercher dans la db de /usr quand l'utilisateur cherche un fichier dans /home?);
      • plus performant parce que l'on peut supposer que seul le $HOME nécessite une mise à jour sans événement scripté (genre un apt update ou apt install)
      • plus portable parce que le $HOME sera un peu plus indépendant du système (donc, il pourra être trimbalé d'une machine à une autre avec moins de conséquences… en supposant que le locate de l'autre système supporte les mêmes options, bien sûr).

      Si tu as un SSD tu peux te dispenser de locate et plutôt utiliser find.

      C'est aussi vrai s'il crée souvent des fichiers: find n'a pas besoin de mettre à jour une base, même s'il est plus lent. Personnellement, je sais que je n'utilise jamais locate, pour cette raison. Après… je devrais peut-être, peut-être qu'il est plus simple de trouver un truc avec locate en excluant un dossier et ses enfants (je crains que je ne comprendrais jamais comment marche --prune… :/)

  • # Bizarre, il me semblait avoir répondu

    Posté par  . Évalué à 2.

    Merci pour vos réponses. J'étais persuadé d'avoir répondu mais il a du y avoir un problème sur le forum ou, le plus probable, j'ai oublié de valider ma réponse.

    J'ai effectivement un SSD et donc un peu approfondi le fonctionnement de find ce qui m'a permis de découvrir l'option -exec ce qui me permet de résoudre le problème à la source de mon questionnement locate / find à savoir rechercher un fichier dont je connais le nom mais pas le chemin ni la casse et l'éditer :

    find ~ -iname toto.odt -exec libreoffice {} ';'

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.