En sistemas similares a UNIX a lo largo de los años (lo más relevante para mí, Linux), he notado que .(directorio actual) nunca está en el estado $PATHpredeterminado. ¿Por qué es esto?
Recuerdo haber leído hace años que era un problema de seguridad, pero el artículo que leí no explicaba exactamente cuál era el problema. ¿Es porque alguien podría dejar una versión maliciosa lso cpen un directorio, y terminaría ejecutándola sin darme cuenta de que estaba allí?
Respuestas:
Respondiste correctamente tu propia pregunta, esa es exactamente la razón por la cual el punto no está en el camino:
para protegerte contra virus infantiles o errores honestos.
Por supuesto, esta es una medida de antivirus muy poco convincente e inútil, y nada le impide agregar puntos a la ruta usted mismo.
-rfen el directorio (hace rm *interesante) ;-)
-rfen primer lugar? ;)
Sí. Si pones el "." en la ruta, terminaría enviando muchas llamadas de comando a los archivos en su directorio actual.
Incluso si fue el último, todavía hay un error piloto. Por ejemplo, Solaris 10 carece de "top". Escribo "top" en mi sistema todo el día, porque creo que estoy en un sistema que tiene "top".
Lo siento, me gustaría preguntar esto en forma de un comentario a la respuesta seleccionada, pero todavía no tengo ningún representante en superusuario.
La respuesta de seguridad tiene sentido, pero si pones "." en su RUTA como la última cosa, ¿no debería mirar el shell en el directorio actual al buscar ejecutables, y así reducir el riesgo de seguridad? Si buscara $ PATH en orden, encontraría / bin / ls antes de encontrar ./ls.
Entonces, qué inseguro es para mí poner "." al final de mi variable de entorno $ PATH?
Funciona como sugiero. Así es como lo probé:
Primero, agregue "." al final de su variable de entorno PATH.
Luego, coloque el siguiente archivo en algún directorio, como ~ / dir1 / dir2 / test_which.rb:
#!/your/path/to/ruby
puts "this file is from the current directory"Y ponga este archivo en /usr/bin/test_which.rb
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"Asegúrese de chmod + x los archivos para que sean ejecutables.
Ahora, si cambia el directorio a ~ / dir1 / dir2 y ejecuta test_which.rb, obtendrá el resultado
this file is at /usr/bin/test_which.rbDe hecho, si ejecuta "which test_which.rb" desde cualquier lugar, debería informar
/usr/bin/test_which.rbTodavía puede ejecutar el archivo en el directorio actual escribiendo:
./test_which.rbdco sl, o sduoen una cáscara, y fue salvado por el "comando no encontrado". Siempre.
ls(salida de color y más) con alias lque prescinde completamente de errores tipográficos.
Más que un riesgo de seguridad, tener '.' en la RUTA hacen casi imposible asegurarse de que la ejecución de cualquier comando actúe según lo previsto. Piense en ejecutar un comando como 'zip' en un directorio enorme que contiene miles de archivos con nombres aleatorios. La posibilidad de que uno de ellos se llame realmente 'zip' no es insignificante y provocaría un error que es muy difícil de entender (en realidad, el archivo debe ser ejecutable, lo que, sin embargo, podría suceder).
En particular, esto es cierto cuando se escriben scripts que mantienen la variable PATH del usuario. Un buen guión escrito debe tratar con todos los casos de esquina (como nombres de archivo con espacios en ellos o comenzando con '-'). Pero no es práctico evitar que se ejecute un archivo en el directorio actual en lugar de un comando del sistema ...
lsserá/usr/bin/lsy./lsno lo será. También existe el obstáculo de que si sabe cómo agregar.al final de su camino, probablemente tenga alguna idea de lo que está haciendo. root nunca debería tener.en el camino, muchos sistemas ya ni siquiera permiten que root inicie sesión.