Should scripts that require sudo fail if they don't have it, or use sudo and prompt?

Question

I have a script which gives me fine-grained control over my backlight brightness and requires sudo to run. It's essentially this:

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

and lives at ~/bin/backlight-adjust. The script needs sudo privileges, because tee $backlight is writing to a privileged location. So it'll fail if it's not run with sudo.

This approach has a problem, because I can't just run sudo backlight-adjust, because ~/bin is not in the $PATH in the sudo environment, only in my environment. So I'd have to to run sudo env "PATH=$PATH" backlight-adjust or something similar.

Alternatively, I could have written it like this:

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

and prompt me for the password.

The second approach works better for me because I don't have to remember to type sudo; it'll prompt me. And I can keep my $PATH intact. This feels more convenient overall, but are there any reasons why I shouldn't do it the second way?

(I'm running Xubuntu 14.04 and my shell is GNU bash 4.2.45, if that makes a difference.)

Answer 1

Personally, I would use a different approach. Make an alias for your script. Add this line to your ~/.bashrc (or equivalent in other shells)

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

That way, you don't need to worry about remembering to run it with sudo and you don't need to add the sudo to the script. It will be completely transparent to you and simply ask for your password when you try and run backlight-adjust.

Answer 2

I can't see why it could be incorrect --- although I normally prefer that commands would not ask things to me, so that they are scriptable. You can tweak /etc/sudoers to have that sudo working without a password.

But... why not adding

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

in your /etc/rc.local and forget about sudo?

(In Ubuntu if you are able to use sudo you are in the sudo group, so you can use chgrp sudo /sys... and be happy with it.)

Answer 3

Alternatively, you could add

Defaults        env_keep +="PATH"

to your /etc/sudoers file.

Answer 4

You state sudo backlight-adjust, because ~/bin is not in the $PATH in the sudo environment

So why depend on that? I think you should just change that line to /home/user/bin/backlight-adjust and it will work.

But I'd really like Terdon's solution of using an alias also. Or you could place your script in /usr/bin/ and it will be available for every user (incl. root)

Answer 5

Can't give a general rule... if the script/program is designed to do some reconfiguring (e.g. a printer) and be called by regular users, it has to. Otherwise, I'd leave well enough alone: If a regular user runs it, just fail (either as a result of an explicit check, or just because it isn't allowed to do something).

Elevated privileges should be handed out sparingly, if at all. Switching to higher privilege is tricky, better leave it to the experts (i.e., sudo(1)).

Answer 6

I personally use something like ${SUDO} in my scripts, so that the caller can set it if needed, or ${SUDO:-sudo} to use it by default.

In your specific case, I’m with the accepted answer, though.

Answer 7

Put the script (without the sudo) in a proper user-wide location, like /bin, and then do this:

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

This works by setting the setuid flag, which means it will always be run as the file owner. For details please read http://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/. I don't really know all that much about how this works, I just found it googling based on something I thought I read a few years ago.