Hace un tiempo estaba instalando NPM y noté que cuando intenté ejecutar su script de instalación de shell usando sudo, arrojaba errores relacionados con algunos comandos que no se encontraban. Sin embargo, al intentar ejecutar el mismo script sin sudo, todo funcionó de maravilla.
Soy un nuevo usuario de Linux, pero según tengo entendido, los permisos y la visibilidad de Sudo son un superconjunto del usuario normal.
¿Por que sucede?
Respuesta1
Según tengo entendido, los permisos y la visibilidad de Sudo son un superconjunto del usuario normal.
Permisos, sí, pero no necesariamente visibilidad. La visibilidad de las aplicaciones se rige por la PATHvariable ambiental.
~$ printenv PATH
/home/vanadium/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/games
Cuando se escribe un comando, el intérprete de comandos primero verifica si es un comando interno o si el comando corresponde con el nombre de un archivo ejecutable en el disco. Luego, el sistema busca en los directorios enumerados PATHhasta que encuentra un archivo ejecutable con un nombre que coincida con el comando.
Como puede ver en el ejemplo, un usuario puede tener directorios privados adicionales en PATH, buscados solo cuando este usuario emite el comando. Así, sí, una cuenta de usuario puede tener distintos comandos disponibles que el rootusuario, es decir, el administrador, rol que asume cuando utiliza el sudocomando.
Aún así, los permisos de un ejecutable determinan en última instancia quién puede ejecutar el archivo. Siempre que los permisos lo permitan, siempre se puede ejecutar un ejecutable proporcionando el nombre de ruta completo en el mensaje, por ejemplo, /usr/bin/mounten lugar de sólo el nombre del archivo, mount. Y, de hecho, rootsiempre se puede ejecutar siempre que el bit ejecutable esté establecido, aunque sea solo para el propietario.
Respuesta2
Digamos que desea ejecutar un archivo en los scripts de su directorio. ejecutarías:
myscript.sh
y el script funciona bien. Pero después de ejecutar sudo, el error que aparece es este:
sudo: myscript.sh: file not found
Siempre que se utiliza sudo, utiliza la ruta del usuario root. La solución sería ejecutar el comando de esta manera:
sudo ./myscript.sh
Respuesta3
El shell (bash, etc.) utiliza diferentes variables en modo usuario normal y sudo. Simplemente verifique esto siguiendo el procedimiento:
# Plain user
printenv > env1
# Using sudo
sudo printenv > env2
# Comparison
diff env1 env2
# Alternative comparison using the GUI tool meld
meld env1 env2
Si meld no está instalado, puede instalarlo fácilmente. Es muy útil.
sudo apt-get update
sudo apt-get install meld
El contenido diferente de las variables de usuario simple/sudo puede influir en el comportamiento del shell y la funcionalidad del script.
Los permisos de acceso a archivos también son diferentes.
Respuesta4
En realidad, es un poco más complicado que eso. Hay un par de definiciones que deben existir en /etc/sudoers.
Las banderas de control que determinan lo que sucede con el sudomedio ambiente son: env_check, env_keepy env_reset.
Elpágina de manual para sudoershace un buen trabajo explicando esto en la sección "Entorno de comando":
$ man --pager="less -p '^\ *Command environment'" sudoers
En una configuración de Ubuntu lista para usar, PATHse llama al indicador definido secure_path(habilitado de forma predeterminada). El valor se utiliza en lugar del usuario PATHpara iniciar sudoporque env_resettambién está habilitado de forma predeterminada:
$ man sudoers | egrep "^\ *secure_path" -A4 | sed 's/^ *//'
secure_path If set, sudo will use this value in place of the user's PATH environment variable. This option can be used to reset the PATH to a known good
value that contains directories for system administrator commands such as /usr/sbin.
Users in the group specified by the exempt_group option are not affected by secure_path. This option is not set by default.
(Editar: la última línea de arriba se refiere a que exempt_groupno está habilitado de forma predeterminada, no a secure_path)
Puedes modificarlo usando visudo(recomendado) o visualizarlo:
$ sudo grep secure_path /etc/sudoers
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Otras veces, los comandos están integrados en bash (como echo) y no son un ejecutable al que pueda hacer referencia en una PATHvariable. Estas son las ocasiones en las que tienes que canalizar algún valor en un sudo bash -cootras maneras.