Parece que nadie más ha abordado la preocupación obvia aquí. Poner sudo
dentro de su script que luego distribuye promueve malos hábitos de usuario . (Supongo que lo está distribuyendo porque menciona "desde el punto de vista del usuario").
La verdad es que hay una directriz en el uso de aplicaciones y scripts que es similar al principio de seguridad en la banca de: Nunca dé su información personal a alguien que lo llame y diga que está llamando "desde su banco" , y que existe por razones similares
La regla para las aplicaciones es:
Nunca escriba su contraseña cuando se le solicite, a menos que esté seguro de lo que se está haciendo con ella. Esto se aplica por triplicado a cualquier persona con sudo
acceso.
Si está escribiendo su contraseña porque se ejecutó sudo
en la línea de comando, genial. Si lo está escribiendo porque ejecutó un comando SSH, está bien. Si lo está escribiendo cuando inicia sesión en su computadora, genial, por supuesto.
Si solo ejecuta un script o ejecutable extranjero e ingresa su contraseña cuando se le solicite, no tiene idea de lo que el script está haciendo con él. Podría estar almacenándolo en un archivo temporal en texto plano, por lo que sabes, e incluso podría fallar al limpiarlo.
Obviamente, hay preocupaciones separadas y adicionales sobre la ejecución de un conjunto desconocido de comandos como root
, pero de lo que estoy hablando aquí es de mantener la seguridad en la contraseña . Incluso suponiendo que la aplicación / script no sea malicioso, aún desea que su contraseña se maneje de manera segura para evitar que otras aplicaciones la consigan y la usen maliciosamente.
Entonces, mi propia respuesta personal a esto es que lo mejor que puede incluir en su script si necesita privilegios de root es:
#!/bin/bash
[ "$UID" -eq 0 ] || { echo "This script must be run as root."; exit 1;}
# do privileged stuff, etc.
exec
: llámese a sí mismo pero al mismo tiempo reemplace el proceso, para que no generemos múltiples instancias del script