¿Deberían fallar los scripts que requieren sudo si no lo tienen, o usar sudo y prompt?

26

Tengo un script que me da un control preciso sobre el brillo de la retroiluminación y requiere sudoejecutarlo. Es esencialmente esto:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | tee $backlight

y vive en ~/bin/backlight-adjust. El script necesita sudoprivilegios, porque tee $backlightestá escribiendo en una ubicación privilegiada. Por lo tanto, fallará si no se ejecuta con sudo.

Este enfoque tiene un problema, porque no puedo simplemente ejecutarlo sudo backlight-adjust, porque ~/binno está $PATHen el sudoentorno, solo en mi entorno. Entonces tendría que correr sudo env "PATH=$PATH" backlight-adjusto algo similar.

Alternativamente, podría haberlo escrito así:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | sudo tee $backlight

y me pide la contraseña.

El segundo enfoque funciona mejor para mí porque no tengo que recordar escribir sudo; me avisará Y puedo mantener mi $PATHintacto. Esto se siente más conveniente en general, pero ¿hay alguna razón por la que no debería hacerlo de la segunda manera?

(Estoy ejecutando Xubuntu 14.04 y mi shell es GNU bash 4.2.45, si eso hace la diferencia).

John Feminella
fuente
Gracias por la corrección. Estoy ejecutando un Debian modificado (LMDE) y mi sudorealmente mantiene mi $PATHpor defecto, así que no tengo este problema.
terdon

Respuestas:

27

Personalmente, usaría un enfoque diferente. Haz un alias para tu guión. Agregue esta línea a su ~/.bashrc(o equivalente en otros shells)

alias backlight-adjust='sudo ~/bin/backlight-adjust'

De esa manera, no necesita preocuparse por recordar ejecutarlo sudoy no necesita agregar sudoel script. Será completamente transparente para usted y simplemente solicitará su contraseña cuando intente ejecutar backlight-adjust.

terdon
fuente
Este parece un enfoque muy sensato, y el que tiene un impacto mínimo en el resto del sistema. +1.
John Feminella
@JohnFeminella Por otro lado, si alguna vez quieres compartir este script con alguien más, también necesitarán el alias. Personalmente, no veo ninguna razón para no incluir sudoel script real, especialmente porque eso le permite ver fácilmente qué elementos del script realmente requieren permisos de root.
Kyle Strand
@KyleStrand no, no lo harán. El comando invocado por el script simplemente se quejará de no tener acceso.
terdon
@terdon Reconozco que podría haber sido un poco más claro, pero presumiblemente ya sabes lo que quise decir: el destinatario del guión se enfrentará al mismo problema al que se enfrentó originalmente el autor del guión, y como un colaborador de guiones concienzudo, el autor debería También comparta su solución personal a este dilema de uso particular.
Kyle Strand
@KyleStrand sí, pero no hubo problema, el único problema que tuvo el OP fue que no quería "tener que recordar escribir sudo", aparte de eso, el script será perfectamente portátil. Mi punto es que el alias es completamente opcional y no resuelve nada, solo lo hace más fácil de usar.
terdon
7

No puedo ver por qué podría ser incorrecto, aunque normalmente prefiero que los comandos no me pregunten cosas, por lo que son programables. Puede ajustar /etc/sudoerspara que sudofuncione sin una contraseña.

Pero ... ¿por qué no agregar

chgrp  one-of-your-groups-here /sys/class/backlight/acpi_video0/brightness     
chmod g+w /sys/class/backlight/acpi_video0/brightness 

en tu /etc/rc.localy olvidarte sudo?

(En Ubuntu, si puedes usarlo, sudoestás en el grupo sudo , así que puedes usarlo chgrp sudo /sys...y estar contento con él).

Rmano
fuente
3

Alternativamente, podría agregar

Defaults        env_keep +="PATH"

a su /etc/sudoersarchivo

Gatito
fuente
2

Usted estado sudo retroiluminación ajustar, porque ~ / bin no está en el $ PATH en el entorno de sudo

Entonces, ¿por qué depender de eso? Creo que deberías cambiar esa línea /home/user/bin/backlight-adjusty funcionará.

Pero realmente me gustaría la solución de Terdon de usar un alias también. O puede colocar su script /usr/bin/y estará disponible para todos los usuarios (incluida la raíz)

ExploWare
fuente
Sí, pero es molesto hacer eso. De lo contrario, ¿cuál fue el punto de ponerlo en mi $ PATH en primer lugar? Además, me gusta tenerlo ~/binporque está bajo el repositorio de archivos de puntos de mi casa, por lo que permanece en el control de versiones.
John Feminella
@JohnFeminella, por cierto, no hay razón para cambiar de ruta, solo use la -Ebandera para preservar el medio ambiente:sudo -E command
terdon
@terdon Eso no funciona en Debian; se anula por razones de seguridad. Tendría que pasar las variables de entorno explícitamente, como mencioné en mi pregunta ( sudo env "PATH=$PATH" ...).
John Feminella
1

No se puede dar una regla general ... si el script / programa está diseñado para realizar una reconfiguración (por ejemplo, una impresora) y debe ser llamado por usuarios habituales, debe hacerlo. De lo contrario, lo dejaría bastante bien: si un usuario normal lo ejecuta, simplemente falla (ya sea como resultado de una verificación explícita o simplemente porque no se le permite hacer algo).

Los privilegios elevados se deben entregar con moderación, si es que lo hacen. Cambiar a un privilegio superior es complicado, mejor déjelo en manos de los expertos (es decir, sudo(1)).

vonbrand
fuente
0

Yo personalmente uso algo como ${SUDO}en mis scripts, para que la persona que llama pueda configurarlo si es necesario, o ${SUDO:-sudo}para usarlo de forma predeterminada.

Sin embargo, en su caso específico, estoy con la respuesta aceptada.

mirabilos
fuente
-1

Coloque el script (sin el sudo) en una ubicación adecuada para todo el usuario, como /bin, y luego haga esto:

sudo chown root /bin/backlight-adjust
sudo chmod 4755 /bin/backlight-adjust

Esto funciona configurando el indicador setuid, lo que significa que siempre se ejecutará como el propietario del archivo. Para más detalles, lea http://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/ . Realmente no sé mucho sobre cómo funciona esto, lo encontré buscando en Google basado en algo que pensé que leí hace unos años.

AJMansfield
fuente
1
Los scripts de Shell ya no se pueden configurar, gracias a Dios ... Esta es una respuesta completamente malvada, ya sabes. En cuanto a la seguridad, especialmente.
mirabilos
@mirabilos Solo es peligroso si el grupo o las banderas de escritura generales están activadas El riesgo con setuid es que cualquier persona con permisos de escritura para el archivo puede ejecutar lo que quiera como si fuera el usuario, por lo que son estos permisos de escritura los que deben protegerse. 4755significa siempre ejecutado como propietario, el propietario puede leer, escribir y ejecutar, el grupo puede leer y ejecutar, y los usuarios pueden leer y ejecutar, que es el nivel de permiso estándar para las cosas que cualquier usuario debería poder hacer con permisos de root.
AJMansfield
@mirabilos Y la idea de que los scripts de shell con setuid introducen más vulnerabilidades que los binarios con setuid es simplemente una tontería; los binarios tampoco son inmunes al exploit ptrace, que es el exploit principal que aprovecha el setuid.
AJMansfield
2
Todos los sistemas operativos actuales tipo Unix prohíben los scripts setuid. Esto es solo un hecho. Pregúnteles por razones usted mismo si no me cree. Comience con OpenBSD.
mirabilos