¿Por qué sudo cambia la RUTA?

Esta es la variable PATH sin sudo:

$ echo 'echo $PATH' | sh /opt/local/ruby/bin:/usr/bin:/bin 

Esta es la variable PATH con sudo:

 $ echo 'echo $PATH' | sudo sh 

/ usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin: / usr / X11R6 / bin

Por lo que puedo decir, se supone que sudo deja intacto a PATH. ¿Que esta pasando? ¿Cómo cambio esto? (Esto está en Ubuntu 8.04).

ACTUALIZACIÓN: por lo que puedo ver, ninguno de los scripts comenzó como cambio de ruta de acceso de ninguna manera.

Del hombre sudo:

Para evitar la falsificación de comandos, sudo comprueba “. ” Y “ ” (ambos que denotan el directorio actual) al buscar un comando en la RUTA del usuario (si uno o ambos están en la RUTA). Sin embargo, tenga en cuenta que la variable de entorno PATH real no se modifica y se pasa sin cambios al progtwig que sudo ejecuta.

Esto es una función molesta una característica de sudo en muchas distribuciones.

Para evitar este “problema” en ubuntu, hago lo siguiente en mi ~ / .bashrc

 alias sudo='sudo env PATH=$PATH' 

Tenga en cuenta que lo anterior funcionará para los comandos que no restablecen $ PATH. Sin embargo, `su ‘restablece que es $ PATH, por lo que debe usar -p para indicarle que no lo haga. ES DECIR:

 sudo su -p 

En caso de que alguien más se ejecute a través de esto y quiera simplemente deshabilitar todos los cambios de variable de ruta para todos los usuarios.
Acceda a su archivo sudoers utilizando el comando: visudo . Debería ver la siguiente línea en alguna parte:

Predeterminado env_reset

que debes agregar lo siguiente en la siguiente línea

¡Defaults! Secure_path

secure_path está habilitado de forma predeterminada. Esta opción especifica qué hacer $ PATH al sudoear. El signo de exclamación desactiva la función.

PATH es una variable de entorno, y como tal es restablecida por sudo por defecto.

Necesita permisos especiales para poder hacer esto.

Del man sudo

        -E La opción -E (preservar el entorno) anulará el env_reset
            opción en sudoers (5)).  Solo está disponible cuando el partido
            El comando ing tiene la etiqueta SETENV o la opción setenv está establecida en sudo-
            ers (5).
        Las variables de entorno que se establecerán para el comando también pueden transmitirse
        la línea de comando en forma de VAR = valor, por ejemplo
        LD_LIBRARY_PATH = / usr / local / pkg / lib.  Variables pasadas en el comando
        línea están sujetos a las mismas restricciones que las variables ambientales normales
        ables con una excepción importante.  Si la opción setenv está configurada en
        sudoers, el comando que se ejecutará tiene la etiqueta SETENV establecida o el comando
        emparejado es TODO, el usuario puede establecer variables que se utilizarían de forma excesiva:
        licitado  Ver sudoers (5) para más información.

Un ejemplo de uso:

 cat >> test.sh env | grep "MYEXAMPLE" ; ^D 
 sh test.sh MYEXAMPLE=1 sh test.sh # MYEXAMPLE=1 MYEXAMPLE=1 sudo sh test.sh MYEXAMPLE=1 sudo MYEXAMPLE=2 sh test.sh # MYEXAMPLE=2 

actualizar

 hombre 5 sudoers: 

      env_reset Si se establece, sudo reiniciará el entorno para que solo contenga
                        el LOGNAME, SHELL, USER, USERNAME y SUDO_ * varían
                        ables.  Cualquier variable en el entorno de la persona que llama que
                        Haga coincidir las listas env_keep y env_check.
                        Los contenidos por defecto de env_keep y env_check
                        listas se muestran cuando sudo es ejecutado por root con el
                        -V opción.  Si sudo se compiló con SECURE_PATH
                        opción, su valor se usará para el entorno PATH
                        variable.  Esta bandera está activada por defecto.

Por lo tanto, puede ser necesario verificar que esto no esté comstackdo.

Es por defecto en Gentoo

 # ( From the build Script ) .... ROOTPATH=$(cleanpath /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin${ROOTPATH:+:${ROOTPATH}}) .... econf --with-secure-path="${ROOTPATH}" 

¡Parece que este error ha existido por bastante tiempo! Aquí hay algunas referencias a fallos que pueden serle útiles (y puede querer suscribirse / votar, insinuar, dar pistas …):


Error Debian # 85123 (“sudo: SECURE_PATH aún no puede ser anulado”) (¡desde 2001!)

Parece que el Bug # 20996 todavía está presente en esta versión de sudo. El registro de cambios dice que puede anularse en tiempo de ejecución, pero todavía no he descubierto cómo.

Mencionan poner algo así en su archivo sudoers:

 Defaults secure_path="/bin:/usr/bin:/usr/local/bin" 

pero cuando lo hago en Ubuntu 8.10 al menos, me da este error:

 visudo: unknown defaults entry `secure_path' referenced near line 10 

Error de Ubuntu # 50797 (“sudo construido con –with-secure-path es problemático”)

Peor aún, por lo que puedo decir, es imposible volver a especificar secure_path en el archivo sudoers. Entonces, si, por ejemplo, desea ofrecer a sus usuarios un acceso fácil a algo en / opt, debe recomstackr sudo.


Sí. Debe haber una manera de anular esta “característica” sin tener que volver a comstackr. Nada peor que fanáticos de la seguridad que le dicen lo que es mejor para su entorno y luego no le da una manera de apagarlo.


Esto es realmente molesto Sería prudente mantener el comportamiento actual por defecto por razones de seguridad, ¡pero debería haber una manera de anularlo además de recomstackrlo desde el código fuente! Muchas personas necesitan la herencia de PATH. Me pregunto por qué los mantenedores no lo investigan, lo que parece fácil de encontrar con una solución aceptable.


Trabajé alrededor de esto así:

 mv /usr/bin/sudo /usr/bin/sudo.orig 

luego crea un archivo / usr / bin / sudo que contenga lo siguiente:

 #!/bin/bash /usr/bin/sudo.orig env PATH=$PATH "$@" 

entonces su sudo regular funciona igual que el sudo no seguro


Error de Ubuntu # 192651 (“ruta de sudo siempre se restablece”)

Dado que un duplicado de este error se presentó originalmente en julio de 2006, no estoy seguro de cuánto tiempo ha estado en funcionamiento un env_keep ineficaz. Sean cuales sean los méritos de forzar a los usuarios a emplear trucos como el mencionado anteriormente, seguramente las páginas man para sudo y sudoers deben reflejar el hecho de que las opciones para modificar el PATH son efectivamente redundantes.

La modificación de la documentación para reflejar la ejecución real no es desestabilizadora y es muy útil.


Error de Ubuntu # 226595 (“imposible de retener / especificar RUTA”)

Necesito poder ejecutar sudo con carpetas binarias no estándar adicionales en la RUTA. Después de haber agregado mis requisitos a / etc / environment, me sorprendió cuando recibí errores sobre comandos faltantes al ejecutarlos bajo sudo …..

Intenté lo siguiente para solucionar esto sin éxito:

  1. Usar la opción ” sudo -E ” – no funcionó. Mi ruta actual todavía fue reiniciada por sudo

  2. Cambiar ” Defaults env_reset ” a ” Defaults !env_reset ” en / etc / sudoers – tampoco funcionó (incluso cuando se combina con sudo -E)

  3. env_reset (por ejemplo, ” #Defaults env_reset “) en / etc / sudoers – tampoco funcionó.

  4. Agregando ‘ Defaults env_keep += "PATH" ‘ a / etc / sudoers – tampoco funcionó.

Claramente, a pesar de la documentación del hombre, sudo está completamente codificado con respecto a PATH y no permite ninguna flexibilidad con respecto a la retención de la RUTA de los usuarios. Muy molesto porque no puedo ejecutar software no predeterminado bajo permisos de root usando sudo.

Esto pareció funcionar para mí

 sudo -i 

que toma el camino no sudo

Creo que de hecho es deseable reiniciar sudo el PATH: de lo contrario, un atacante que haya comprometido su cuenta de usuario podría colocar versiones de todos los tipos de herramientas en la RUTA de sus usuarios, y se ejecutarían al usar sudo.

(Por supuesto, tener sudo reset the PATH no es una solución completa a este tipo de problemas, pero ayuda)

Esto es de hecho lo que sucede cuando usas

 Defaults env_reset 

en / etc / sudoers sin usar exempt_group o env_keep .

Esto también es conveniente porque puede agregar directorios que solo son útiles para la raíz (como /sbin y /usr/sbin ) a la ruta de sudo sin agregarlos a las rutas de acceso de los usuarios. Para especificar la ruta que va a utilizar sudo:

 Defaults secure_path="/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin" 

Funciona ahora usando sudo de los repositorys kármicos. Detalles de mi configuración:

 root@sphinx:~# cat /etc/sudoers | grep -v -e '^$' -e '^#' Defaults env_reset Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/grub-1.96/sbin:/opt/grub-1.96/bin" root ALL=(ALL) ALL %admin ALL=(ALL) ALL root@sphinx:~# cat /etc/apt/sources.list deb http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe deb http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe deb http://security.ubuntu.com/ubuntu jaunty-security main restricted universe deb-src http://security.ubuntu.com/ubuntu jaunty-security main restricted universe deb http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe deb http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe deb http://security.ubuntu.com/ubuntu karmic-security main restricted universe deb-src http://security.ubuntu.com/ubuntu karmic-security main restricted universe root@sphinx:~# root@sphinx:~# cat /etc/apt/preferences Package: sudo Pin: release a=karmic-security Pin-Priority: 990 Package: sudo Pin: release a=karmic-updates Pin-Priority: 960 Package: sudo Pin: release a=karmic Pin-Priority: 930 Package: * Pin: release a=jaunty-security Pin-Priority: 900 Package: * Pin: release a=jaunty-updates Pin-Priority: 700 Package: * Pin: release a=jaunty Pin-Priority: 500 Package: * Pin: release a=karmic-security Pin-Priority: 450 Package: * Pin: release a=karmic-updates Pin-Priority: 250 Package: * Pin: release a=karmic Pin-Priority: 50 root@sphinx:~# apt-cache policy sudo sudo: Installed: 1.7.0-1ubuntu2 Candidate: 1.7.0-1ubuntu2 Package pin: 1.7.0-1ubuntu2 Version table: *** 1.7.0-1ubuntu2 930 50 http://au.archive.ubuntu.com karmic/main Packages 100 /var/lib/dpkg/status 1.6.9p17-1ubuntu3 930 500 http://au.archive.ubuntu.com jaunty/main Packages root@sphinx:~# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin root@sphinx:~# exit exit abolte@sphinx:~$ echo $PATH /home/abolte/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/chromium-17593:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/xpra-0.0.6/bin abolte@sphinx:~$ 

Es maravilloso finalmente tener esto resuelto sin usar un truco.

 # cat .bash_profile | grep PATH PATH=$HOME/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin export PATH # cat /etc/sudoers | grep Defaults Defaults requiretty Defaults env_reset Defaults env_keep = "SOME_PARAM1 SOME_PARAM2 ... PATH" 

Solo comenta “Default env_reset” en / etc / sudoers

Solo edita env_keep en /etc/sudoers

Se ve algo como esto:

Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE"

Simplemente agregue PATH al final, así que después del cambio se vería así:

Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE PATH"

Cierre la terminal y luego ábrala nuevamente.

Secure_path es tu amigo, pero si quieres liberarte de secure_path simplemente hazlo

 sudo visudo

Y anexar

 Valores predeterminados exempt_group = your_goup

Si desea eximir a un grupo de usuarios, cree un grupo, agréguelo a todos los usuarios y utilícelo como su grupo exento. hombre 5 sudoers por más.

la solución recomendada en los comentarios en la distro de OpenSUSE sugiere cambiar:

 Defaults env_reset 

a:

 Defaults !env_reset 

y luego presumiblemente para comentar la siguiente línea que no es necesaria:

 Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE" 

comentan que tanto “Default env_reset” como “Default secure_path …” en el archivo / etc / sudores funcionan para mí

También puede mover su archivo en un directorio utilizado sudoers:

  sudo mv $HOME/bash/script.sh /usr/sbin/ 

Er, no es realmente una prueba si no agregas algo a tu camino:

 bill @ bill-desktop: ~ $ ls -l / opt / pkg / bin
 total 12
 -rwxr-xr-x 1 root root 28 2009-01-22 18:58 foo
 bill @ bill-desktop: ~ $ que foo
 / opt / pkg / bin / foo
 bill @ bill-desktop: ~ $ sudo su
 root @ bill-desktop: / home / bill # which foo
 root @ bill-desktop: / home / bill # 

La ruta se restablecerá cuando se use su o sudo según la definición de ENV_SUPATH y ENV_PATH definida en /etc/login.defs

$ PATH es una variable de entorno y significa que el valor de $ PATH puede diferir para otros usuarios.

Cuando está iniciando sesión en su sistema, su configuración de perfil decide el valor de $ PATH .

Ahora, veamos:

 User | Value of $PATH -------------------------- root /var/www user1 /var/www/user1 user2 /var/www/html/private 

Supongamos que estos son los valores de $ PATH para diferentes usuarios. Ahora cuando está ejecutando cualquier comando con sudo, en el significado real el usuario root ejecuta ese comando.

Puede confirmar ejecutando estos comandos en la terminal:

 user@localhost$ whoami username user@localhost$ sudo whoami root user@localhost$ 

Esta es la razón. Creo que es claro para ti.