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

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:

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

  • Thanks for the correction. I'm running a modified Debian (LMDE) and my sudo actually keeps my $PATH by default so I don't have this issue. – terdon Mar 18 '14 at 21:47

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.

  • This seems like a very sensible approach, and the one with minimal impact on the rest of the system. +1. – John Feminella Mar 18 '14 at 19:46
  • @JohnFeminella On the other hand, if you ever want to share this script with anyone else, they'll need the alias, too. Personally, I don't see any reason not to put sudo in the actual script, especially since that allows you to easily see which elements of the script actually require root permissions. – Kyle Strand Mar 19 '14 at 17:36
  • @KyleStrand no they won't. The command called by the script will simply complain about not having access. – terdon Mar 19 '14 at 17:37
  • @terdon I recognize that I could have been slightly clearer, but presumably you know what I meant: the recipient of the script will face the same problem originally faced by the author of the script, and as a conscientious script-sharer, the author should also share their personal solution to this particular usage dilemma. – Kyle Strand Mar 19 '14 at 17:46
  • @KyleStrand yes, but there was no problem, the only issue the OP had was that he didn't want to "have to remember to type sudo" apart from that, the script will be perfectly portable. My point is that the alias is completely optional and doesn't solve anything, it just makes it easier to use. – terdon Mar 19 '14 at 17:55

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


Alternatively, you could add

Defaults        env_keep +="PATH"

to your /etc/sudoers file.


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)

  • Yes, but it's annoying to do that. Otherwise, what was the point of putting it in my $PATH in the first place? Also, I like having it in ~/bin because then it's under my home's dotfiles repository, so it stays in version-control. – John Feminella Mar 18 '14 at 21:28
  • @JohnFeminella by the way, there's no reason to change path, just use the -E flag to preserve the environment: sudo -E command – terdon Mar 18 '14 at 21:43
  • @terdon That doesn't work in Debian; it's overridden for security reasons. You'd have to pass the environment variables explicitly, as I mentioned in my question (sudo env "PATH=$PATH" ...). – John Feminella Mar 18 '14 at 21:46

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


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.


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.

  • 1
    Shell scripts cannot be setuid any more, thanks goodness… This is an utterly evil answer, you know. Security-wise, especially. – mirabilos Mar 19 '14 at 10:07
  • @mirabilos Its only dangerous if the group or general write flags are on. The risk with setuid is that anyone with write permissions for the file can run anything they like as if they were the user, and so it is these write permissions that need to be protected. 4755 means always executed as owner, owner can read, write, and execute, group can read and execute, and users can read and execute, which is the standard permission level for things any user should be allowed to do with root permissions. – AJMansfield Mar 19 '14 at 15:12
  • @mirabilos And the idea that shell scripts with setuid introduce more vulnerabilities than binaries with setuid is just silly; binaries are not immune to the ptrace exploit either, which is the main exploit that takes advantage of setuid. – AJMansfield Mar 19 '14 at 15:18
  • 2
    All current Unix-like OSes forbid setuid scripts. This is just a fact. Ask them for reasons yourself if you don't believe me. Start with OpenBSD. – mirabilos Mar 19 '14 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.