Puede probar otras implementaciones de localización que indexan archivos accesibles para todo el mundo en un índice legible para todo el mundo, normalmente ubicado en /var/lib/locate/locatedb o /var/cache/locate/locatedb o algo así.
No veo mucha necesidad de una lista de archivos para escalar su acceso en un servidor típico. Por lo general, sabrá qué aplicación está atacando y recuperará sus archivos de configuración y su base de datos y obtendrá las credenciales de esta manera. Puede probar archivos como .netrc , .ssh/id_rsa y .ssh/config para ver si la cuenta puede ser una puerta de entrada a otras cuentas. Si no está seguro de lo que se está ejecutando en el cuadro, pruebe muchos nombres de archivo plausibles.
Lo único que es un poco largo para agotar son los valores PID, para explorar lo que se está ejecutando. Se necesitan 32k solicitudes para agotar pid_t en Linux de forma predeterminada, y puede verificar el valor máximo en /proc/sys/kernel/pid_max . La línea de comando está en /proc/PID/cmdline; no puede ver la lista de archivos abiertos (necesita readlink para eso) pero puedes ver su contenido (cat /proc/PID/fd/0 …).
Para el caso específico de un servicio de compilación, verifique los archivos de configuración de ese servicio. Eso debería ayudarlo a ubicar el repositorio de git. Si ha podido ubicar un git checkout, busque en .git/index y .git/logs/HEADS y quizás otros archivos en .git/logs (experimente con ese servicio para ver qué sucursales se usan y qué operaciones usa). Esto debería permitirle recuperar ID de objetos que luego puede leer desde .git/objects .
Aparte de encontrar una base de datos de localización, no puedo pensar en una forma de elevar el acceso de archivos de lectura a archivos de lista con una configuración típica.