Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

share|improve this question
    
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 at 21:47
add comment

7 Answers 7

up vote 26 down vote accepted

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.

share|improve this answer
    
This seems like a very sensible approach, and the one with minimal impact on the rest of the system. +1. –  John Feminella Mar 18 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 at 17:36
    
@KyleStrand no they won't. The command called by the script will simply complain about not having access. –  terdon Mar 19 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 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 at 17:55
show 2 more comments

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

share|improve this answer
add comment

Alternatively, you could add

Defaults        env_keep +="PATH"

to your /etc/sudoers file.

share|improve this answer
add comment

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)

share|improve this answer
    
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 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 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 at 21:46
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
Shell scripts cannot be setuid any more, thanks goodness… This is an utterly evil answer, you know. Security-wise, especially. –  mirabilos Mar 19 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 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 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 at 15:48
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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