Help Limit Sudo Access For Script
 

I have a developer on my Linux server who needs to have a small custom Bash script ran manually which lives in /etc/init.d/ folder:

I don't just want to give this or possibly more developers blind full sudo access to the entire server. My question is how can I limit the users sudo access to run this script and not have to give them more access than they need? I'm not sure if it's necessary to see what exactly the script is doing and where it's doing it so I will just leave it at this for now and can post more details if need be.

So I just want this user to be able to run this scrip as sudo but have sudo limit her ability to what she can and can't do as an elevated user.

Thanks for any info.

Not difficult. In your sudoers, just add:

Then she should be able to run only that script as sudo, and not be able to run any other commands as sudo.

However, you probably want to ensure she doesn't have write access to the script (otherwise she could put 'sh' in there and get a full shell!). So you want to take a copy of her script, make sure she can't alter the copy, and then allow her to run the copy as sudo.

...additionally:
no, as long as you're aware of what it does and how it does it. Might be stating the obvious but if a script allows the user to 'su -l' (or see 'man sudoers': NOEXEC examples), well, then that's it.

Indeed; some cmds/tools do allow (or can be 'crashed' to allow) access to a shell.
Have a good read of the sudoers page http://linux.die.net/man/5/sudoers, with special ref to the Security Notes & Preventing Shell Escapes sections at the bottom there ...

Note that the perms you've got at the moment allow anyone to run it, without sudo...
You could possibly create a dedicated group for just running that file and only put that one user in that group and use group execute perms; no need for sudo.

Actually I think you do need to know what it does, as well as HOW.

One thing to restrict is parameters. The script may be subject to something like

sudo script '`/usr/bin/sh`'

Or some other shenanigans with parameters, environment, or other substitutions...

That actually is what I said. You only read what I wrote differently :-]