6

I'm setting up a new machine (well actually, an Ubuntu VM) and am trying to write a script to setup a few common things that I use when doing this (Git, curl, vim + janus).

So my script looks a bit like this:

#setup
#!/bin/sh
sudo apt-get install git
sudo apt-get install curl
...

It doesn't seem great to have 'sudo' mixed in with my command -- that is just my security-spidey-sense tingling. It seems like something like the following might also work:

sudo setup

Is there a better way to do this? What are your rules of thumb when you write scripts and need elevated permissions?

Improve this question

3 Answers 3

Reset to default
11

There is no problem using multiple 'sudo' calls in scripts.

I find it better than running the whole scripts as root as the risks are limited by restricting the privilege elevation to the commands that really need them.

Improve this answer
1
  • 1
    This is a good point that I didn't think about. I actually like the idea of fine-grained 'sudo'. Thank-you for your comments!
    – Jimmy Lyke
    Sep 8, 2011 at 2:01
2

I've done it both ways. I think the security risks are the same: if someone edits the script, you'll execute undesired commands. So make sure write permissions are restricted.

I tend to put sudo in the script if I don't want the whole script to run as root. If the script runs for a long time (I write scripts to build gcc or other big projects), multiple calls to sudo may prompt the user more than once, which can be annoying.

Improve this answer
1
  • Great point on the editing of this script. I did not think about the length of some of the tasks -- have you considered nesting scripts together: Calls that need sudo put into a separate script, use 'sudo' on that one to get it started. It is a blend of your answer and jillagre's answer.
    – Jimmy Lyke
    Sep 8, 2011 at 2:05
0

I would say no. Not unless you have a good reason to. I work in a big financial company with very strict security practices, so one of the things we do is take away sudo from everyone, then grant it back selectively.

One of the IDs we take it away from is root. This means that if I'm installing an RPM with "sudo rpm ...", I'm doing it as root, which is fine, but if that RPM then in its scripts attempts sudo, it will fail--because, again, we locked even root out of global sudo.

Now if we happen to have selectively granted sudo back for specific commands, it might happen to work if 100% of the RPM sudo calls are things that root has been given. But the chances of that are slim.

We have had trouble with sudo inside RPM scripts. Better to just leave it out I think. Or at least keep in mind that there are companies like mine where you may not know who has sudo for what, and even root may not have it.

Improve this answer
2
  • 1
    sudo is about taking root's identity, and you can't really take root's identity... from root. Besides, post-install scripts are bound to the RPM, which probably implies that these scripts already run as root (and if so, their developers have no interest in using sudo, not to mention that RPM scripts shouldn't be interactive). Now, a good idea would be to block everyone out of the root account so that they all have to use sudo, therefore submitting themselves to its security policy.
    – John WH Smith
    Jan 9, 2015 at 14:50
  • Agreed. The vendor with which we had the issue agreed it was wrong to have sudo in their RPM scripts and removed them in the next release. Oddly, it worked on a out-of-the-box server despite being odd. But on our corporate semi-locked down servers (i.e. we lock down root but are super-liberal with giving sudo), it choked. Not only that, the vendor install instructions said to use sudo to run yum to install the RPM, so the script was, in fact, already running as root. All that to say, don't put sudo in RPM scripts, then do have the entire thing run as sudo.
    – James Madison
    Jan 11, 2015 at 3:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .