script de shell: ¿usar sudo dentro de él vs ejecutarlo con sudo?

Al escribir un script de shell, en el que algunos, pero no todos los comandos, necesitan privilegios de superusuario, ¿debo

• agregue sudo a los comandos que necesitan privilegios de superusuario y ejecute el script de shell sin sudo, o

• no agregue sudo a esos comandos que necesitan privilegios de superusuario, pero ejecute el script de shell con sudo?

De la segunda forma, solo tendré que proporcionar mi contraseña una vez, pero todos los comandos del script se ejecutarán con privilegios de superusuario, incluidos los comandos que no se necesitan.

De la primera manera, es posible que deba proporcionar mi contraseña varias veces para diferentes comandos sudo, mientras que los privilegios de superusuario se otorgan solo a aquellos comandos que los necesitan.

Por cuestiones de seguridad, la primera forma es mejor. Por conveniencia, la segunda forma es mejor.

1. He estado pensando en adoptar la primera forma. Así que tengo que lidiar con los inconvenientes de proporcionar mis contraseñas a múltiples comandos sudo en el script de shell.

2. Stephen Harris escribió :

   Un script bien escrito detectaría si se estaba ejecutando con los permisos correctos y no llamaría a sudo, pero hay muchos scripts malos

   Entonces, ¿debería usar la segunda forma? Si es así,

   • ¿Cómo puedo escribir "el script detectaría si se ejecuta con los permisos correctos y no llama a sudo en absoluto"?

   • ¿Cómo puedo mejorar su seguridad para evitar el problema de otorgar privilegios de superusuario a los comandos que no los necesitan al ejecutar el script con sudo?

3. ¿Tendría este enfoque simple lo mejor de ambos enfoques: agregar sudo a los comandos que solo lo necesitan y ejecutar el script con o sin sudo dependiendo de si quiero conveniencia o seguridad? ¿Este enfoque tiene algún problema?

Gracias.

Para abordar su primer problema:

¿Cómo puedo escribir "el script detectaría si se ejecuta con los permisos correctos y no llama a sudo en absoluto"?

Hay una verificación simple y POSIX para root:

#!/bin/sh
is_user_root ()
{
    [ "$(id -u)" -eq 0 ]
}

Alternativamente, en Bash, los codificadores más orientados al rendimiento pueden querer usar:

#!/bin/bash
is_user_root ()
{
    [ ${EUID:-$(id -u)} -eq 0 ]
}

Tenga en cuenta que intencionalmente envolví el código en funciones para su reutilización.

Para abordar su segundo problema:

¿Cómo puedo mejorar su seguridad para evitar el problema de otorgar privilegios de superusuario a los comandos que no los necesitan al ejecutar el script con sudo?

No puedes hacer mucho al respecto. Al menos no se me ocurre nada. Si vi el guión, podría tener sugerencias. Pero como no lo incluyó en su pregunta ... Si ejecuta todo el script con sudoo como root, no veo forma de controlar esto.

Para abordar el comentario:

¿Qué opinas de "usar sudo dentro de él vs ejecutarlo con sudo"

En mis guiones, generalmente procedo con el último enfoque, pero eso no significa necesariamente que se lo recomiendo. Porque depende de para quién está destinado el guión, rootsolo por ; para usuarios principalmente con la excepción de tener algunos usuarios con sudoderechos; tendrías que incluir literalmente tu guión en la pregunta para poder responder con cualquier valor.

Creo que puedo responder esto.

Entonces, ¿debería usar la segunda forma?

No hay ninguna razón por la que deba tener un problema aquí, esta es la razón:

Si solo hay un comando que necesita ejecutarse como root, entonces runsu programa como rooto sudoporque sudodentro de su script es el camino más largo. ¿Has olvidado que los programadores son flojos?

Si necesita muchos comandos runcomo root, ejecútelo como rooto sudo.

¿Cómo puedo mejorar su seguridad para evitar el problema de otorgar privilegios de superusuario a los comandos que no los necesitan al ejecutar el script con sudo?

Si otros usuarios necesitan runsu programa, configúrelos sudoporque sudoes muy personalizable y satisfará sus necesidades.

Aquí hay un ejemplo con sudo:

Utilice siempre visudoal editar el archivo sudoers .....

kate ALL=(ALL) NOPASSWD: /usr/local/bin/script ARG1 ARG2

sudo También es ideal para cambiar usuarios dentro de su programa / script. Aquí hay una línea de uno de los scripts míos:

sudo -i -u "$user" user="$user" CURRENTDIR="$CURRENTDIR" BASHRC="$BASHRC" bash <<'EOF'

¿Cómo puedo escribir "el script detectaría si se ejecuta con los permisos correctos y no llama a sudo en absoluto"?

https://www.cyberciti.biz/tips/shell-root-user-check-script.html
how-do-i-determine-if-a-shell-script-is-running-with-root-permissions

bash/sh:

#!/bin/bash
# (Use #!/bin/sh for sh)
if [ `id -u` = 0 ] 
then
        echo "I AM ROOT, HEAR ME ROAR"
fi

csh:

#!/bin/csh
if ( `id -u` == "0" ) 
then
        echo "I AM ROOT, HEAR ME ROAR"
endif

#!/bin/bash
if [[ $EUID -ne 0 ]]; then
  echo "You must be a root user" 2>&1
  exit 1
else
  mount /dev/sdb1 /mnt/disk2
fi

EDITAR a pedido del señor @terdon:

Piensa en tu guión de esta manera ...

¿Es un script público (otras personas que no lo usarán) ¿Qué hace el script? ¿Te dice la hora? ¿O actualiza iptables en 200 sistemas? Si solo lo usa, ¿está relacionado con el trabajo / profesional o es para uso personal?

Solo tiene que saber de antemano en qué consiste su grupo de usuarios, eso es todo.

Si es writtenpara dar o vender a los administradores, incluso entonces, ¿por qué no debería scriptpermitirse que se ejecute como root? ¿Qué daño puede hacer?

Los scripts / programas reales se ejecutan a menudo como el usuario privilegiado y nadie menciona que eso no es un problema, pero cuando los programadores, en su mayoría novatos como yo, hablan de estas cosas, entonces es una amenaza de seguridad real ... lo que el tipo en tu publicación te referirse a lo que está tratando de decir, aunque no con elegancia, es que algunas personas miran el control que usted tiene del systemcódigo y de usted ... ¿configura los archivos con más permisos de los que va a usar, tiene todas las verificaciones en su ¿es lógico o el programador talentoso va a ver los peligros en su código simplemente mirándolo?

Si su code needs root, uso sudo, y si hay muchos simplemente se ejecuta como root....... termina mi respuesta aquí uf