web-dev-qa-db-fra.com

localiser vs trouver: utilisation, avantages et inconvénients les uns des autres

Dans les systèmes Linux et Unix, il existe deux commandes de recherche courantes: locate et find .

Quels sont les avantages et les inconvénients de chacun? Quand l'un a des avantages sur l'autre?

filesfindsearchlocate
138
m0nhawk

locate(1) n'a qu'un seul gros avantage sur find(1): la vitesse.

find(1), cependant, a de nombreux avantages par rapport à locate(1):

  • find(1) est primordiale, pour revenir à la toute première version d'AT & T Unix . Vous le trouverez même dans les Linux embarqués réduits via Busybox . C'est tout sauf universel.

    locate(1) est beaucoup plus jeune que find(1). L'ancêtre le plus ancien de locate(1)n'est apparu qu'en 198 , et il n'était pas largement disponible en tant que "locate" jusqu'en 1994, date à laquelle il a été adopté - dans GNU findutils et dans 4.4BSD .

  • locate(1) est également non standard , il n'est donc pas installé par défaut partout. Certains systèmes d'exploitation de type POSIX ne la proposent même pas en option, et là où elle est disponible, l'implémentation peut manquer des fonctionnalités souhaitées car il n'y a pas de norme indépendante spécifiant le jeu de fonctionnalités minimum qui doit être disponible.

    Il existe une norme de facto , étant BSD locate(1) , mais ce n'est que parce que les deux autres les principales versions de locate implémentent toutes ses options: -0, -c, -d, -i, -l, -m, -s Et -S. mlocate implémente 6 options supplémentaires qui ne sont pas dans BSD locate: -b, -e, -P, -q, --regex Et -w. GNU locate implémente ces six plus un autre quatre : -A, -D, -E Et -p. (J'ignore les alias et les différences mineures comme -? Vs -h Vs --help.)

    Les BSD et Mac OS X livrent BSD locate.

    La plupart des Linux sont livrés GNU locate, mais Red Hat Linux et Arch sont livrés à la place mlocate. Debian n'installe pas non plus dans son installation de base, mais propose les deux versions dans ses référentiels de packages par défaut; si les deux sont installés en même temps, "locate" exécute mlocate.

    Oracle expédie mlocate dans Solaris depuis le 11.2 , publié en décembre 2014. Auparavant, locate n'était pas installé par défaut sur Solaris. (Vraisemblablement, cela a été fait pour réduire l'incompatibilité des commandes de Solaris avec Oracle Linux , qui est basé sur Red Hat Enterprise Linux , qui utilise également mlocate.)

    IBM AIX ne fournit toujours aucune version de locate, au moins à partir d'AIX 7.2 , sauf si vous installez GNU = findutils dans AIX Toolbox for Linux Applications .

    HP-UX également apparaît pour manquer locate dans le système de base.

    Les anciens "vrais" Unix n'incluaient généralement pas d'implémentation de locate.

  • find(1) possède une syntaxe d'expression puissante, avec de nombreuses fonctions, opérateurs booléens , etc.

  • find(1) peut sélectionner des fichiers avec plus qu'un simple nom. Il peut sélectionner par:

    • âge
    • taille
    • propriétaire
    • type de fichier
    • horodatage
    • autorisations
    • profondeur dans le sous-arbre ...

  • Lors de la recherche de fichiers par nom, vous pouvez effectuer une recherche à l'aide de syntaxe de globalisation de fichier dans toutes les versions de find(1), ou dans GNU ou BSD, en utilisant - expressions régulières .

    Les versions actuelles de locate(1) acceptent les modèles globaux comme le fait find, mais BSD locate ne fait pas du tout de regex. Si vous êtes comme moi et devez utiliser une variété de types de machines, vous préférez le filtrage grep au développement d'une dépendance à -r Ou --regex.

    locate a besoin d'un filtrage plus fort que find parce que ...

  • find(1) ne recherche pas nécessairement tout le système de fichiers. Vous le pointez généralement vers un sous-répertoire, un parent contenant tous les fichiers sur lesquels vous souhaitez qu'il opère. Le comportement typique d'une implémentation locate(1) est de vomir tous les fichiers correspondant à votre modèle, le laissant au filtrage grep et ainsi de réduire son éruption à sa taille.

    (Astuce maléfique: locate / Vous obtiendra probablement une liste de tous les fichiers du système!)

    Il existe des variantes de locate(1) comme slocate(1) qui limitent la sortie en fonction des autorisations utilisateur, mais ce n'est pas la version par défaut de locate dans n'importe quel système d'exploitation majeur.

  • find(1) peut faire des choses aux fichiers qu'il trouve, en plus de simplement les trouver. L'opérateur le plus puissant et le plus largement supporté est -exec, Mais il y en a d'autres. Dans les récentes implémentations GNU et BSD find, par exemple, vous avez les opérateurs -delete Et -execdir.

  • find(1) s'exécute en temps réel, donc sa sortie est toujours à jour.

    Étant donné que locate(1) repose sur une base de données mise à jour des heures ou des jours dans le passé, sa sortie peut être obsolète. (C'est le problème de cache périmé .) Cette pièce a deux faces:

    1. locate peut nommer des fichiers qui n'existent plus.

      GNU locate et mlocate ont le drapeau -e Pour lui faire vérifier l'existence du fichier avant d'imprimer le nom de chaque fichier qu'il a découvert dans le passé, mais cela ronge certains l'avantage de vitesse locate, et n'est pas disponible dans BSD locate en plus.

    2. locate ne nommera pas les fichiers créés depuis la dernière mise à jour de la base de données.

    Vous apprenez à vous méfier quelque peu de la sortie de locate, sachant que cela peut être faux.

    Il existe des moyens de résoudre ce problème, mais je ne connais aucune implémentation largement utilisée. Par exemple, il y a rlocate , mais il apparaît pour ne fonctionner contre aucun noyau Linux moderne.

  • find(1) n'a jamais plus de privilèges que l'utilisateur qui l'exécute.

    Étant donné que locate fournit un service global à tous les utilisateurs d'un système, il souhaite que son processus updatedb s'exécute en tant que root pour pouvoir voir l'intégralité du système de fichiers. Cela conduit à un choix de problèmes de sécurité:

    1. Exécutez updatedb en tant que root, mais rendez son fichier de sortie lisible dans le monde pour que locate puisse s'exécuter sans privilèges spéciaux. Cela expose efficacement les noms de tous les fichiers du système à tous les utilisateurs. Cela peut suffire à une faille de sécurité pour causer un vrai problème.

      BSD locate est configuré de cette façon sur Mac OS X et FreeBSD.

    2. Écrivez la base de données comme lisible uniquement par root et créez locatesetuid root pour qu'il puisse lire la base de données. Cela signifie que locate doit effectivement réimplémenter le système d'autorisation du système d'exploitation afin qu'il ne vous montre pas les fichiers que vous ne pouvez pas normalement voir. Cela augmente également la surface d'attaque de votre système, en risquant spécifiquement une attaque escalade racine .

    3. Créez un utilisateur ou un groupe spécial "locate" pour posséder le fichier de base de données et marquez le binaire locate comme setuid/setgid Pour cet utilisateur/groupe afin qu'il puisse lire la base de données. Cela n'empêche pas en soi les attaques par escalade de privilèges, mais il atténue considérablement les dommages que l'on pourrait causer.

      mlocate est configuré de cette façon sur Red Hat Enterprise Linux .

      Cependant, vous avez toujours un problème, car si vous pouvez utiliser un débogueur sur locate ou le faire dump core vous pouvez accéder à des parties privilégiées de la base de données.

    Je ne vois pas de moyen de créer une commande locate vraiment "sécurisée", à moins de l'exécuter séparément pour chaque utilisateur du système, ce qui annule une grande partie de son avantage sur find(1).

En bout de ligne, les deux sont très utiles. locate(1) est préférable lorsque vous essayez simplement de trouver un fichier particulier par son nom, dont vous savez qu'il existe, mais vous ne vous souvenez simplement pas où il se trouve exactement. find(1) est préférable lorsque vous avez une zone ciblée à examiner ou lorsque vous avez besoin de l'un de ses nombreux avantages.

174
Warren Young

locate utilise une base de données prédéfinie, qui doit être régulièrement mise à jour, tandis que find parcourt un système de fichiers pour localiser les fichiers.

Ainsi, locate est beaucoup plus rapide que find, mais peut être inexact si la base de données - peut être vue comme un cache - n'est pas mise à jour (voir la commande updatedb).

De plus, find peut offrir plus de granularité, car vous pouvez filtrer les fichiers par chaque attribut de celui-ci, tandis que locate utilise un modèle correspondant aux noms de fichiers.

36
user435943

find n'est pas possible pour un novice ou un utilisateur occasionnel d'Unix d'utiliser avec succès sans lire attentivement la page de manuel. Historiquement, certaines versions de find n'avaient même pas par défaut le -print option, ajoutant à l'hostilité de l'utilisateur.

locate est moins flexible, mais beaucoup plus intuitif à utiliser dans le cas courant.

7
Russell Borogove

Un léger inconvénient de Locate est qu'il peut ne pas indexer la zone du système de fichiers qui vous intéresse. Sur les systèmes de bureau Debian, par exemple Linux Mint 17.2, le fichier /etc/updatedb.conf est configuré pour exclure certaines zones de la considération , y compris/tmp,/var/spool et /home/.ecryptfs.

Ignorer /home/.ecryptfs empêche les noms de fichiers dans les répertoires chiffrés d'être exposés à des utilisateurs non autorisés. Cependant, si votre répertoire personnel est crypté avec ecryptfs, cela signifie également que votre répertoire personnel n'est pas indexé, et Locate ne trouvera donc jamais rien dans votre répertoire personnel. Cela pourrait le rendre largement inutile pour vous (c'est le cas pour moi). En plus de ne pas trouver de résultats, le processus updatedb chargera périodiquement votre disque sans aucun avantage, et pourrait tout aussi bien être désactivé si vous êtes le principal ou le seul utilisateur du système.

2
Jim