¿Hay alguna diferencia entre ejecutar una tarea intensiva sobre sudo con los siguientes comandos ?:
- nice sudo [comando intensivo aquí]
- sudo nice [comando intensivo aquí]
Por cierto, esto es para Linux 3.x.
¿Hay alguna diferencia entre ejecutar una tarea intensiva sobre sudo con los siguientes comandos ?:
Por cierto, esto es para Linux 3.x.
Respuestas:
Hay una diferencia, crucial.
Si desea disminuir la prioridad del proceso, el orden no importa. Por otro lado, si quieres aumentarlo , debes ponerlo sudo
antes nice
.
Como está ejecutando el comando como un usuario normal (de lo contrario no se molestaría con sudo), solo puede disminuir la prioridad de su comando. Pero si lo usa sudo
primero, puede aumentarlo si lo desea.
Si ejecuta, también nice sudo
se le solicitará su contraseña, pero como pasará mucho más tiempo escribiéndola, realmente no importa mucho.
Como señaló ThoriumBR, si está bajando la prioridad, entonces el orden es irrelevante, pero si desea aumentar la prioridad, entonces (ya que esto debe hacerse como raíz) debe usar sudo nice
.
De lo contrario, no puedo imaginar ninguna diferencia real.
Usando el 'principio de privilegio mínimo' solo debe ejecutar un programa con privilegios de root si los necesita, y luego soltarlos nuevamente tan pronto como ya no los necesite.
Entonces, sí, hay una diferencia, si hay un exploit para nice, un atacante podría ejecutar código con los mismos privilegios que el buen programa.
Además, sudo restablece su entorno, por lo que podría tener efectos secundarios, intente
$ echo 'echo $PATH' | sh
/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/jens/.local/bin:/home/jens/bin:/home/jens/.local/bin
$ echo 'echo $PATH' | sudo sh
[sudo] password for jens:
/sbin:/bin:/usr/sbin:/usr/bin
Entonces, el comando 'agradable' que ejecuta a través de sudo podría terminar siendo un binario diferente.
$ which ash
~/.local/bin/ash
$ sudo which ash
[sudo] password for jens:
which: no ash in (/sbin:/bin:/usr/sbin:/usr/bin)
Respuesta tardía:
Si su acceso a sudo está limitado a ciertos programas ( foo
y bar
, por ejemplo), entonces no tendrá autoridad para ejecutar sudo nice foo
, pero se le permitirá ejecutar nice sudo foo
.
nice bash -c 'ps -p $$ -o pid,ni,comm'
, vea , ysudo nice bash -c 'ps -p $$ -o pid,ni,comm'
, ynice sudo bash -c 'ps -p $$ -o pid,ni,comm'
. Los tres deberían mostrarle el buen valor para la identificación del proceso ($$) del shell generado.