Depende en gran medida de cómo llame a su programa con sudo o su .
P.ej. en el sistema en el que estoy en este momento:
.bashrc
COMMAND $HOME $USER Env. $PATH
1. sudo -i (root) root root [1]
2. sudo -s (USER) root USER /home/${USER}/bin:[1]
3. sudo /bin/bash (USER) root USER /home/${USER}/bin:[1]
4. sudo su (root) root USER [1]:/usr/games:/usr/local/games
5. sudo su - (root) root root [1]
Donde [1]=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Env=Las variables de entorno se restablecen para 1 y 5, tomadas de $USER en 2,3,4.
Entonces, un script o un programa que se inicia con una opción diferente puede ver diferentes $PATH , $HOME , su shell puede leer diferentes .bashrc ,.profile y variables de entorno. Lee el archivo relacionado con el $HOME . Cada usuario puede modificar su entorno de forma diferente (variables, $PATH , .bashrc, .profile, .bash_profile, alias...). En particular, un usuario puede tener un orden diferente de los directorios en su $PATH y, como consecuencia, un script puede ejecutar un comando, p. en /home/$USER/bin en su lugar, el que está en la ruta esperada desde la raíz.
Puede ejecutar el programa bajo sudo -i ya que estaba registrado como root con su - ,pero puede tener un comportamiento diferente si lo ejecuta con sudo MyCommand o con su -c MyCommand .
Desde man su :
En la parte de descripción:
El entorno actual se pasa al nuevo shell . El valor de $PATH se restablece a /bin:/usr/bin para usuarios normales, o/sbin:/bin:/usr/sbin:/usr/bin para el superusuario
...
En la parte de opciones:
- , -l, --iniciar sesión
Proporcionar un entorno similar al lo que el usuario esperaría si el usuario haya iniciado sesión directamente .
Del hombre sudo
-i , --acceso
Ejecute el shell especificado por la entrada de la base de datos de contraseñas del usuario de destino como un shell de inicio de sesión. Esto significa que el shell leerá los archivos de recursos específicos de inicio de sesión, como .profile o .login. Si se especifica un comando, se pasa al shell para su ejecución a través de la opción -c del shell. Si no se especifica ningún comando, se ejecuta un shell interactivo. sudo intenta cambiar al directorio de inicio de ese usuario antes de ejecutar el shell. El comando se ejecuta con un entorno similar al que recibiría un usuario al iniciar sesión . La sección Entorno de comandos en el manual de sudoers(5) documenta cómo la opción -i afecta el entorno en el que se ejecuta un comando cuando se usa la política de sudoers.
Si tiene completo sudo acceso, puedes convertirte en root usando sudo su - , por lo que el punto de seguridad es discutible.
De hecho, hay una manera de discernir la diferencia entre un programa ejecutado como root y un programa se ejecutó bajo sudo - usando getuid contra geteuid - pero esto es un truco artificial. ¿Por qué haría eso un sistema de parches?
Hay algunas diferencias si obtiene un shell raíz, como lo señala @Hastur.
Si no está obteniendo un shell raíz, entonces hay más diferencias. El miembro de soporte puede tener experiencia tratando de hacer cosas como sudo patch -p0 < /root/patch.file donde patch se ejecuta como root, pero < (tuberías de un archivo) no lo es.