Vous pouvez essayer d'autres implémentations de localisation qui indexent les fichiers accessibles par le monde dans un index lisible par le monde, généralement situé à /var/lib/locate/locatedb ou /var/cache/locate/locatedb ou quelque chose comme ça.
Je ne vois pas vraiment la nécessité d'une liste de fichiers pour augmenter votre accès sur un serveur typique. Habituellement, vous savez quelle application vous attaquez et récupérez ses fichiers de configuration et sa base de données et obtenez les informations d'identification de cette façon. Vous pouvez essayer des fichiers tels que .netrc , .ssh/id_rsa et .ssh/config pour voir si le compte peut être une passerelle vers d'autres comptes. Si vous n'êtes pas sûr de ce qui peut être exécuté sur la boîte, essayez beaucoup, beaucoup de noms de fichiers plausibles.
La seule chose qui est un peu longue à épuiser, ce sont les valeurs PID, pour explorer ce qui tourne. Il faut 32 000 requêtes pour épuiser pid_t sous Linux par défaut, et vous pouvez vérifier la valeur maximale dans /proc/sys/kernel/pid_max . La ligne de commande est en /proc/PID/cmdline; vous ne voyez pas la liste des fichiers ouverts (vous avez besoin de readlink pour cela) mais vous pouvez voir leur contenu (cat /proc/PID/fd/0 …).
Pour le cas spécifique d'un service de build, vérifiez les fichiers de configuration de ce service. Cela devrait vous aider à localiser le référentiel git. Si vous avez pu localiser un git checkout, regardez dans .git/index et .git/logs/HEADS et peut-être d'autres fichiers en .git/logs (expérimentez avec ce service pour voir quelles branches sont utilisées et quelles opérations il utilise). Cela devrait vous permettre de récupérer les ID d'objet que vous pourrez ensuite lire à partir de .git/objects .
À part trouver une base de données de localisation, je ne vois pas de moyen d'élever l'accès aux fichiers en lecture dans des fichiers de liste avec une configuration typique.