¿Por qué sudo cambia la RUTA?

Esta es la PATHvariable sin sudo:

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

Esta es la PATHvariable 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, sudose supone que debe dejarlo PATHintacto. ¿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 raíz PATHde ninguna manera.

De man sudo:

Para evitar la suplantación de comandos, sudo comprueba ``. '' Y `` '' (ambos 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 programa que ejecuta sudo.

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

Para solucionar 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 los $ PATH ellos mismos. Sin embargo, 'su' restablece su $ PATH, por lo que debe usar -p para decirle que no lo haga. ES DECIR:

sudo su -p

En caso de que alguien más se encuentre con esto y quiera deshabilitar todos los cambios de variables de ruta para todos los usuarios.
Acceder a su archivo sudoers con el comando: visudo. Debería ver la siguiente línea en alguna parte:

Valores predeterminados env_reset

que debe agregar lo siguiente en la siguiente línea

Valores predeterminados! Secure_path

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

PATH es una variable de entorno y, como tal, se restablece de forma predeterminada por sudo.

Necesita permisos especiales para poder hacerlo.

De man sudo

       -E La opción -E (preservar 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á configurada en sudo-
           ers (5).

       Las variables de entorno que se establecerán para el comando también se pueden transmitir
       la línea de comando en forma de VAR = valor, por ejemplo,
        LD_LIBRARY_PATH = / usr / local / pkg / lib. Variables pasadas en el comando
       la línea está sujeta a las mismas restricciones que la variedad de entorno normal
       Ables con una importante excepción. Si la opción setenv está configurada en
       sudoers, el comando a ejecutar tiene la etiqueta SETENV establecida o el comando
       coincidente es TODO, el usuario puede establecer variables que en general serían for-
       Bidden. 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 está configurado, sudo restablecerá el entorno para que solo contenga
                       LOGNAME, SHELL, USER, USERNAME y SUDO_ * vari-
                       ables Cualquier variable en el entorno de la persona que llama que
                       coincide con las listas env_keep y env_check y luego se agregan.
                       El contenido predeterminado de env_keep y env_check
                       las listas se muestran cuando sudo es ejecutado por root con el
                       -V opción. Si sudo se compiló con la SECURE_PATH
                       opción, su valor se utilizará para el entorno RUTA
                       variable. Esta bandera está activada por defecto.

Por lo tanto, es posible que deba verificar que esto esté / no esté compilado.

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 de errores que puede encontrar útiles (y puede que desee suscribirse / votar, pista, pista ...):

Error de Debian # 85123 ("sudo: SECURE_PATH todavía no se puede anular") (¡desde 2001!)

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

Mencionan poner algo como esto en su archivo sudoers:

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

pero cuando hago eso 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 respetar seguras_rutas en el archivo sudoers. Entonces, si, por ejemplo, desea ofrecer a sus usuarios un acceso fácil a algo bajo / opt, debe recompilar sudo.

---

Si. No necesita ser una forma de anular esta "característica" sin tener que recompilar. Nada peor que los fanáticos de la seguridad que le dicen qué es lo mejor para su entorno y luego no le dan una forma de apagarlo.

---

Esto es realmente molesto. Puede ser aconsejable mantener el comportamiento actual de forma predeterminada por razones de seguridad, ¡pero debería haber una forma de anularlo que no sea volver a compilar desde el código fuente! Muchas personas necesitan herencia de RUTA. Me pregunto por qué los encargados del mantenimiento no lo investigan, lo que parece fácil de encontrar una solución aceptable.

---

Lo solucioné así:

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

luego cree 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 de ruta no segura

Error de Ubuntu # 192651 ("la ruta de sudo siempre se restablece")

Dado que un duplicado de este error se archivó originalmente en julio de 2006, no estoy claro cuánto tiempo ha estado en funcionamiento un env_keep ineficaz. Cualesquiera que sean los méritos de obligar a los usuarios a emplear trucos como los enumerados anteriormente, seguramente las páginas de manual para sudo y sudoers deberían reflejar el hecho de que las opciones para modificar la RUTA 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 sorprendí cuando recibí errores sobre la falta de comandos al ejecutarlos en sudo .....

Intenté lo siguiente para solucionar esto sin éxito:

1. Usar la sudo -Eopción " " no funcionó. Mi ruta actual todavía fue restablecida por sudo

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

3. Descomentar env_reset(por ejemplo, " #Defaults env_reset") en / etc / sudoers - tampoco funcionó.

4. Agregar ' 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 retener a los usuarios PATH. Muy molesto ya que no puedo ejecutar software no predeterminado con permisos de root usando sudo.

Esto pareció funcionar para mí.

sudo -i 

que toma el no-sudo PATH

Creo que, de hecho, es deseable que sudo restablezca la RUTA: de lo contrario, un atacante que haya comprometido su cuenta de usuario podría poner versiones de todo tipo de herramientas en la RUTA de sus usuarios, y se ejecutarían al usar sudo.

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

De hecho, esto es lo que sucede cuando usas

Defaults env_reset

en / etc / sudoers sin usar exempt_groupo env_keep.

Esto también es conveniente porque puede agregar directorios que solo son útiles para root (como /sbiny /usr/sbin) a la ruta sudo sin agregarlos a las rutas de sus usuarios. Para especificar la ruta que utilizará sudo:

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

Funciona ahora usando sudo de los repositorios 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 resolver esto 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 comente "Valores predeterminados env_reset" en / etc / sudoers

Solo edita env_keepen/etc/sudoers

Se parece a 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, para que después del cambio se vea 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 eximirte de secure_path solo hazlo

sudo visudo

Y anexar

Valores predeterminados exet_group = your_goup

Si desea eximir a un grupo de usuarios, cree un grupo, agréguelo a todos los usuarios y úselo como su grupo exento. Hombre 5 sudoers para más.

La solución recomendada en los comentarios sobre la distribución de OpenSUSE sugiere cambiar:

Defaults env_reset

a:

Defaults !env_reset

y presumiblemente 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"

comentar tanto "Default env_reset" como "Default secure_path ..." en el archivo / etc / sudores me funciona

También puede mover su archivo en un directorio usado de 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 raíz raíz 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 inicie sesión en su sistema, la configuración de su perfil decidirá el valor de $ PATH .

Ahora, echemos un vistazo: -

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

Suponga que estos son los valores de $ PATH para diferentes usuarios. Ahora, cuando está ejecutando cualquier comando con sudo, entonces, en el sentido 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 está claro para ti.