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

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).

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.

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).

Alternativamente, podría agregar

Defaults        env_keep +="PATH"

a su /etc/sudoersarchivo

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)

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)).

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.

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.