path - peso - porque sudo mucho sin hacer nada

¿Por qué sudo cambia el PATH? (17)

¡Parece que este error ha existido durante bastante tiempo! Aquí hay algunas referencias de errores que pueden resultarle útiles (y es posible que desee suscribirse / votar, sugerencia, sugerencia ...):

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

Parece que el error # 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 aún no he descubierto cómo.

Mencionan poner algo como esto en su archivo de 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

Ubuntu bug # 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 acceso fácil a algo en / opt, debe volver a compilar sudo.
Sí. Debe haber una forma de anular esta "característica" sin tener que volver a compilar. 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 manera de desactivarlo.
Esto es realmente molesto. Puede ser prudente mantener el comportamiento actual por defecto por razones de seguridad, pero debería haber una manera de anularlo de otra manera que no sea compilar desde el código fuente. Muchas personas están necesitando la herencia de PATH. Me pregunto por qué ningún mantenedor lo investiga, lo que parece fácil de encontrar con una solución aceptable.
Trabajé alrededor de esta manera:
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 normal funciona igual que el sudo que no es de ruta segura

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

Dado que originalmente se archivó un duplicado de este error en julio de 2006, no estoy claro cuánto tiempo ha estado funcionando un env_keep ineficaz. Independientemente de los méritos de obligar a los usuarios a emplear trucos como el que se menciona anteriormente, seguramente las páginas de manual de sudo y sudoers deberían reflejar el hecho de que las opciones para modificar el PATH son efectivamente redundantes.
Modificar la documentación para reflejar la ejecución real no es desestabilizador y es muy útil.

Ubuntu bug # 226595 ("imposible de retener / especificar PATH")

Necesito poder ejecutar sudo con carpetas binarias adicionales no estándar en el PATH. Después de haber agregado mis requisitos a / etc / environment, me sorprendió cuando recibí errores sobre la falta de comandos al ejecutarlos bajo sudo ...
Intenté lo siguiente para solucionar esto sin éxito:
Usando la opción " sudo -E " - no funcionó. Mi PATH existente todavía fue restablecido por sudo
Cambiar " Defaults env_reset " a " Defaults !env_reset " en / etc / sudoers - tampoco funcionó (incluso cuando se combinó con sudo -E)
env_reset (por ejemplo, " #Defaults env_reset ") en / etc / sudoers - tampoco funcionó.
Agregar '' Defaults env_keep += "PATH" '' a / etc / sudoers - tampoco funcionó.
Claramente, a pesar de la documentación del hombre, el sudo está completamente codificado con respecto a PATH y no permite ninguna flexibilidad con respecto a la retención de PATH de los usuarios. Muy molesto porque no puedo ejecutar software no predeterminado bajo permisos de root usando sudo.

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, sudo se supone que debe dejar PATH sin tocar. ¿Que esta pasando? ¿Cómo cambio esto? (Esto es en Ubuntu 8.04).

ACTUALIZACIÓN: por lo que puedo ver, ninguno de los scripts se inició como root PATH cambio de ninguna manera.

De man sudo :

Para evitar la suplantación de comandos, sudo verifica las palabras ``. '''' Y `` '''' (ambas denotan el directorio actual) al buscar un comando en la RUTA del usuario (si una o ambas 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.

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 puerta trasera de todo tipo de herramientas en la RUTA de sus usuarios, y se ejecutarían al usar sudo.

(Por supuesto, tener sudo resetea el PATH no es una solución completa para este tipo de problemas, pero ayuda)

Esto es precisamente 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 sudo sin agregarlos a las rutas de los usuarios. Para especificar la ruta a ser utilizada por sudo:

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

En caso de que alguien más se encuentre con esto y quiera deshabilitar todas las variables de ruta que cambian para todos los usuarios.
Accede a tu archivo de sudoers usando el comando: visudo . Deberías ver la siguiente línea en algún lugar:

Valores predeterminados env_reset

el cual deberías agregar lo siguiente en la siguiente línea

Por defecto! Secure_path

secure_path está habilitado por defecto. Esta opción especifica qué hacer $ PATH al realizar sudoing. El signo de exclamación desactiva la función.

Er, no es realmente una prueba si no agrega algo a su 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:~$ which foo /opt/pkg/bin/foo bill@bill-desktop:~$ sudo su root@bill-desktop:/home/bill# which foo root@bill-desktop:/home/bill#

Esto es ~~una función molesta~~ Una característica del 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á con los comandos que no restablecen el $ PATH. Sin embargo, `su ''restablece su $ PATH, por lo que debe usar -p para decirle que no lo haga. ES DECIR:

sudo su -p

Esto pareció funcionar para mí

sudo -i

que toma en el camino no sudo

Funciona ahora usando sudo desde 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 tener finalmente resuelto esto sin usar un hack.

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

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

Defaults env_reset

Defaults !env_reset

y luego, probablemente, 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"

Secure_path es tu amigo, pero si quieres eximirte de secure_path, hazlo

sudo visudo

Y añadir

Defaults 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 para más.

Simplemente comente "Predeterminados env_reset" en / etc / sudoers

Solo edite env_keep en /etc/sudoers

Se ve algo como esto:

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

Cierre la terminal y luego vuelva a abrir.

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

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

comentar tanto "Default env_reset" como "Default secure_path ..." en el archivo / etc / sudores funciona para mí

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

Necesita permisos especiales para poder hacer esto.

Del man sudo

-E The -E (preserve environment) option will override the env_reset option in sudoers(5)). It is only available when either the match- ing command has the SETENV tag or the setenv option is set in sudo- ers(5).

Environment variables to be set for the command may also be passed on the command line in the form of VAR=value, e.g. LD_LIBRARY_PATH=/usr/local/pkg/lib. Variables passed on the command line are subject to the same restrictions as normal environment vari- ables with one important exception. If the setenv option is set in sudoers, the command to be run has the SETENV tag set or the command matched is ALL, the user may set variables that would overwise be for- bidden. See sudoers(5) for more information.

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

man 5 sudoers : env_reset If set, sudo will reset the environment to only contain the LOGNAME, SHELL, USER, USERNAME and the SUDO_* vari- ables. Any variables in the caller''s environment that match the env_keep and env_check lists are then added. The default contents of the env_keep and env_check lists are displayed when sudo is run by root with the -V option. If sudo was compiled with the SECURE_PATH option, its value will be used for the PATH environment variable. This flag is on by default.

Por lo tanto, es posible que deba comprobar que esto 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}"

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

Cuando esté iniciando 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

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

Puede confirmar ejecutando estos comandos en el terminal: -

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

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

# 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"