Llevo años escribiendo la misma línea en cada servidor que monto: export PATH="$PATH:~/.local/bin". Todos la conocen, todos la copian de algún tutorial, parece la cosa más inofensiva del mundo. Esta semana apareció un post que demuestra que ese ~ entre comillas no es tu directorio home, y que el efecto lateral puede ser mucho más feo de lo que uno imagina.
El detalle de Bash que casi nadie lee
Bash solo expande la tilde cuando va sin comillas. Está en la documentación oficial desde hace décadas, pero nadie la lee completa. Cuando pones "$PATH:~/.local/bin" entre comillas dobles, el ~ queda como texto literal. El resultado no es /root/.local/bin: es un PATH que contiene la entrada ~/.local/bin/ tal cual, sin la raíz.
¿Y qué significa una entrada de PATH sin raíz? Que es relativa al directorio donde estés parado en ese momento. O sea: el shell va a buscar binarios en ./~/.local/bin/ de la carpeta actual, no en tu home. El autor del post lo demostró creando un directorio llamado literalmente ./~ en un proyecto, compilando un binario ahí, y corriendolo solo con el nombre: el shell encontró el ejecutable del proyecto, no el del sistema. Tu home nunca intervino.
Por qué esto es un problema de seguridad y no solo una curiosidad
Piensa en lo que haces todos los días en un servidor: entras a un repositorio, descomprimes un paquete, haces git clone de algo que te pasaron. Si el directorio de ese proyecto trae una carpeta ./~/.local/bin/ con binarios que se llaman como los comandos comunes —curl, python3, ssh— y tu PATH tiene la tilde literal, el siguiente comando que escribas ahí puede ejecutar el binario del proyecto en vez del binario del sistema. Sin sudo, sin exploits del kernel, solo con la confusión de la tilde.
Lo que más me gustó del post es el origen de todo: el autor no estaba auditando nada, estaba probando nono, una herramienta de sandboxing para agentes de IA, y fue el sandbox el que lo advirtió: «PATH entries the sandbox can write to». Y eso me tocó directo, porque hoy tengo crones y agentes que se pasean por carpetas de las que en muchos casos no conozco ni el contenido. Un agente que clona un repo y después ejecuta comandos por su nombre es exactamente el escenario donde esta trampa muerde: el directorio del repo decide qué binario corre, no tu configuración.
El chequeo que me hice
Lo primero que hice al leer esto fue auditarme. Un solo comando:
echo "$PATH" | tr ':' '\n' | grep '~'
Si imprime algo, tienes el problema. En mi caso salió limpio, y no por ingenio: por costumbre vieja siempre escribí $HOME/.local/bin en vez de la tilde, así que mi .bashrc y mi .profile están bien de puro suerte. Reconocerlo también es parte de la honestidad: uno puede llevar años con una configuración mala sin que nadie te avise. En una flota de servidores, un chequeo de una línea que corre en 30 segundos vale más que cualquier análisis teórico. Lo he dicho antes y lo repito: la mitad de la auditoría de un VPS son greps contra tu propia configuración.
La corrección, en una línea
Si el grep te tiró algo, la fix es trivial: cambia el ~ por $HOME en tu .bashrc, .zshrc o .profile, y cierra y reabre la sesión. export PATH="$PATH:$HOME/.local/bin" hace exactamente lo que siempre creíste que hacía la otra línea. Nada más, nada menos.
Mi gracia con este bug es que no gana premios ni sale en los advisories con CVE. Es una de esas esquinas del shell que llevan ahí desde antes de que cualquiera de nosotros instalara su primer Linux, y siguen mordiendo gente que lleva años en esto. El PATH es una de las pocas estructuras donde la carpeta donde te paren decide qué código corre con tu usuario, y aun así la tratamos con la misma pereza con que copiamos líneas de tutorial. La próxima vez que agregues una entrada, escríbela con $HOME y quédate tranquilo. Y si administras más de una máquina, corre el grep ahora mismo: la tilde falsa se arregla en un minuto, el binario falso te cuesta caleta más.
Fuente de inspiración: The tilde in your PATH may not be your HOME (disconnect3d.pl)
