Sudo vs root; alguna diferencia real?

44

Estoy trabajando con un miembro de soporte para un producto, y él insiste en que necesito ser root para instalar una serie de parches, y que sudo no funcionará; él no proporciona una razón, pero parece muy firme en sus creencias. Superusuario de navegación No puedo determinar ningún motivo posible para que este sea el caso, y como confirmación, cuando ejecuto:

sudo -l

Yo obtengo:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

Según tengo entendido, obtener acceso del equipo de Linux / servidor para ser realmente root no es un proceso inmediato, por lo que preferiría instalarlos yo mismo.

¿Hay alguna razón práctica por la cual sudo se comportaría de manera diferente a la raíz para instalar software en un servidor?

linux sudo root

— guardabosque
fuente

2

Creo que deberías devolvérselo. Como otros han demostrado, hay una gran variedad de formas de obtener raíces usando sudo y si él no puede proporcionarle una razón concreta de por qué sudo es insuficiente, entonces no tiene una pierna para pararse.

— Garrett

1

Entorno y subcomandos vienen a la mente. Creo que Hastur hizo un buen trabajo con el medio ambiente, y Jayen hizo un buen trabajo con subcomandos, tuberías y redireccionamiento.

— jww

2

Garrett tiene un buen punto, pero antes de entrar en un posible concurso de meadas, le preguntaría al miembro de soporte: ¿lo has intentado en ambos sentidos y ha fallado en uno de esos? Es posible que haya estado en el camino del fracaso con sudolos guiones, ya que los guiones están escritos actualmente. Si ese es el caso, entonces la respuesta sds' podría ser más útil para usted: sudo su -.

— jww

34

Depende en gran medida de cómo llame a su programa con sudoo su.
Por ejemplo, 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.

Por lo que una secuencia de comandos o un programa que se puso en marcha con una opción diferente puede ver diferente $PATH, $HOME, su cáscara puede leer diferentes .bashrc, .profiley las variables de entorno. Lee el archivo relacionado con el $HOME. Cada usuario puede modificar su entorno de una manera diferente (variables $PATH, .bashrc, .profile, .bash_profile, alias ...). En particular, un usuario puede tener un orden diferente de los directorios en el suyo $PATHy, como consecuencia, un script puede ejecutar un comando, por ejemplo, en /home/$USER/binlugar del que se encuentra en la ruta esperada desde la raíz.

Puede ejecutar el programa con el sudo -ique inició sesión como root su -, pero puede tener un comportamiento diferente si lo ejecuta con sudo MyCommando con su -c MyCommand.

De 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 , --login
Proporcione un entorno similar al que el usuario esperaría si el usuario hubiera iniciado sesión directamente .

Del hombre sudo

-i , --login
Ejecuta el shell especificado por la entrada de la base de datos de contraseñas del usuario objetivo 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. sudointenta 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 comando en el manual de sudoers (5) documenta cómo la opción -i afecta el entorno en el que se ejecuta un comando cuando la política de sudoers está en uso.

— Hastur
fuente

Gran respuesta. Todavía soy un novato en Linux, pero ¿hay otra diferencia de que lo que puedes hacer usando sudopuede estar limitado por los permisos en el archivo sudoers frente a hacer cosas como root no tiene esas limitaciones? La última cita de bloque puede implicar eso, pero si lo entiendo correctamente, parece otra diferencia sustancial más allá del medio ambiente (¿o tal vez por el medio ambiente?).

— fijador1234

23

Si tiene sudoacceso completo , puede comenzar a rootusar 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 rooty un programa ejecutado bajo sudo- usando getuidvs geteuid- pero este es un truco artificial. ¿Por qué un sistema de parches haría eso?

— sds
fuente

55

Hablando de su -eso, es posible que desee utilizarlo sudo -ipara tener el mismo entorno que al iniciar sesión directamente.

— Cristian Ciupitu

2

Si ejecuta con, por ejemplo sudo myscript, mantendrá $ PATH y las variables de entorno del shell en el que se encuentra. Si corre con sudo -i myscriptcorre como si iniciara sesión como root. Vea la respuesta con nuestro _zoo de llamadas :-) _

— Hastur

1

Creo que es importante señalar que las variables ambientales pueden no configurarse de la misma manera sudoque iniciar sesión como root

— secretformula

1

@dmanexe: sudo no significa superusuario do, es "cambiar usuario do". su y sudo se pueden usar para cambiar a cualquier usuario en lugar de solo al superusuario. Además, no hay nada pseudo sobre sudo, realmente obtienes la raíz real cuando ejecutas sudo, no algo falso. Tenga en cuenta que la magia de sudo realmente proviene del bit de permiso setuid.

— Mentira Ryan

2

sds, @CharlesDuffy: La idea de que sudo y su causan geteuid()y getuid()son diferentes entre sí es un mito. su y sudo cambian las ID de usuario reales y efectivas a las del usuario de destino antes de ejecutar el comando o shell especificado, excepto en la situación muy inusual en la que los ha configurado explícitamente para que se comporten de otra manera. Puede verificar esto (para sudo) ejecutando sudo id -uy sudo id -ru(ambos muestran 0), leyendo sudo (8) (bajo EJECUCIÓN DE MANDO ), o escribiendo un programa de prueba .

7

Hay algunas diferencias si está obteniendo un shell raíz, como lo señaló @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.filedonde patchse ejecuta como root, pero <(tubería de un archivo) no lo es.

— Jayen
fuente

1

Derecha: el punto de vista práctico a menudo ofrece sugerencias que son más difíciles de detectar solo en las páginas de manual. Para superar una situación similar, se ve obligado a hacer más gimnasia [:-)] por ejemplo, escribir algo como sudo /bin/bash -c "./patch -p0 < /root/patch". Aún más delicado es el caso cuando usa la redirección para crear un archivo >. En la primera forma, creará un archivo que pertenece al usuario solo si tiene suficiente derecho para escribir en el directorio final. De esta última manera, creará un archivo propiedad de root ... el lado oscuro de Unix ;-)

— Hastur

1

Creo que cuando uso el acceso sudo, se crea un archivo de registro, sin embargo, cuando se ejecuta directamente a través del acceso raíz, no lo hay.

— Ashley Redman BSc
fuente

0

Depende de cuán fino desee que sea el acceso raíz. Si tiene varios usuarios que realizan diferentes tareas en un sistema, entonces sudo sería más ideal. Un ejemplo que uso con frecuencia es la necesidad de reiniciar una aplicación o base de datos. La seguridad siempre se hace mejor menos privilegiada. Uso grupos y solo permito que esos grupos realicen acciones explícitas. Un buen libro que describe este proceso es "Sudo Mastery: Control de acceso de usuarios para personas reales". En realidad es un buen libro sobre sudo en general ...

— meredithkm
fuente