203

On busy days, I'd like to run

$ ./configure && make && sudo make install && halt

on the night and go to bed, hoping the application would automatically be installed. But what I see the next day is the screen where sudo asks me for the password. So how could I run sudo with password in one command line, or is there any other method to do this?

Keith Thompson
  • 5,075
  • 2
  • 25
  • 33
Jichao
  • 7,145
  • 12
  • 52
  • 62
  • You need `halt` to run as root. – Keith Thompson Aug 08 '12 at 06:54
  • 2
    Doesn't `sudo` have a 15-minute timeout? Couldn't you run, say, `sudo ls` or something similar, enter your password, and then run the above command, having `sudo` privileges still active? (I can't test this at the moment, otherwise I'd post this as an answer.) – Matt Aug 08 '12 at 08:28
  • 2
    The timeout on `sudo` is configurable. Security-conscious people (aka paranoid, like me) set it to zero... :-) – dda Feb 13 '13 at 04:54
  • Also see [Prompt for sudo password and programmatically elevate privilege in bash script?](https://unix.stackexchange.com/q/28791/56041), [How to enter password only once in a bash script needing sudo](https://askubuntu.com/q/711580), [Request root privilege from within a script](https://askubuntu.com/q/746350), [Create a sudo user in script with no prompt for password...](https://stackoverflow.com/q/43853533/608639), [How to prompt user for sudo password?](https://stackoverflow.com/q/47538572/608639), etc – jww Mar 30 '18 at 17:55
  • `sudo -v`; is the easity way to get sudo to prompt with as a noop. @Matt – nelaaro Apr 21 '21 at 05:27

12 Answers12

316

Yes, use the -S switch which reads the password from STDIN:

$echo <password> | sudo -S <command>

So for your case it would look like this:

$./configure && make && echo <password> | sudo -S make install && halt

of course, replace <password> with your password.

John T
  • 163,373
  • 27
  • 341
  • 348
39

Set HISTIGNORE to "sudo -S"

$ export HISTIGNORE='*sudo -S*'

Then pass your password safely to sudo:

$ echo "your_password" | sudo -S -k <command>

"HISTIGNORE" means to not save this command into the history. That is the history in memory or "~/.bash_history" file.

For example, the below will safely pipe your password to the sudo command, without retaining a history of your password.

“-S”, means to use stdin for the password,

“-k” means to ignore cached credentials to force sudo to always ask. This is for consistent behavior.

$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -k whoami
$ echo "<your_password>" | sudo -S -k cat /etc/shadow
$ echo "<your_password>" | sudo -S -k bash /tmp/myscript.sh

The downside to the above method is that if you want to see the commands you ran in the history later on they won't be there. Another method is to update the sudo authentication credential cache (default is enabled with 5 minutes timeout), then run the sudo separately. But the downside of this is that you'll need to be aware of the 5 minute cache.

For example:

$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -v
$ sudo whoami
$ echo "<your_password>" | sudo -S -v
$ sudo cat /etc/shadow
$ echo "<your_password>" | sudo -S -v
$ sudo /tmp/myscript.sh

Note I ran a sudo before each command to ensure that the sudo cache is updated, as the default is 5 mintues. Yes, whoami shouldn't take 5 minutes, but I figure might as well have it run before each command for consistency. You could also put "export HISTIGNORE='sudo -S'" in your ~/.bashrc file, then load it with ". ~/.bashrc" or logoff then login. However, I'm thinking using this for scripting purposes, so I'll keep it at the top of all my scripts for best security practices. Setting "echo "" | sudo -S -v" to a variable instead might also be a good idea, then just run the variable before each command that needs root privileges, see Janar's comment. "John T"'s comment should also include the "-k" parameter, as if you run "sudo -S" without "-k" and sudo authentication cache already has your credentials (and is still valid, default sudo authentication cache is 5 minutes) then bash will run your password as a command instead, which is bad.

user393365
  • 391
  • 3
  • 3
  • 2
    Just as a small note on making things not available in the history, run your command with a single space at the front of it. For some reason this causes history to ignore it. – Matt Fletcher Aug 02 '17 at 08:20
  • 2
    If you put your password into a command-line parameter, then it will be visible to all in the output of _ps_. Better to put it in a file and use indirection (`sudo -S -v '`) – bobbogo Apr 14 '20 at 17:42
26

You can do this too:

sudo -S <<< "password" command
Jahid
  • 401
  • 4
  • 5
14

You could also configure sudo with visudo to allow you user to use make as sudo without password.

User_Alias USERS = your_user
Cmnd_Alias CMDS = /usr/bin/make
USERS ALL = (ALL) NOPASSWD: CMDS
Natim
  • 1,659
  • 2
  • 15
  • 20
  • 1
    I figured out no need to declare aliases. Add `my_user ALL=(ALL) NOPASSWD: /usr/bin/your_command` is OK. Remember to add it to the end to overwrite other configs. – Junle Li Jan 20 '20 at 12:38
12

Several of the other solutions have the disadvantage that they unnecessarily run ./configure and make as root.

This is a bit convoluted, but it should work:

sudo sh -c "su $USER -c ./configure && su $USER -c make && make install && halt"

Note the use of double quotes to allow $USER to be expanded by the (non-root) shell.

I might also add a sleep 60 before the halt command. I've sometimes done things like this, expecting the command to run for a long time, but something goes wrong and it terminates immediately; the sleep lets me kill the command before the system shuts down. Or you can use shutdown with a time argument.

Keith Thompson
  • 5,075
  • 2
  • 25
  • 33
12

You could replace your command line with this:

$sudo su

$./configure && make && make install && halt

You will be prompted for your password immediately, then the rest of the commands will run as superuser.

CarlF
  • 8,846
  • 3
  • 24
  • 40
  • 8
    an alternate (and probably preferred) version of this: `sudo sh -c "./configure && make && make install && halt"` – quack quixote Nov 09 '09 at 03:51
  • 2
    But then wouldn't all the generated compile files have the superuser permissions? This would prevent you from running ./configure && make as a regular user later. – user45909 Aug 04 '13 at 23:35
  • Yes, user45909, you're quite right. I have personally never rerun ./configure && make except after downloading an update of the main package anyway, but I'm probabably not typical. – CarlF Aug 06 '13 at 19:48
  • Still great for all kinds of general use, such as copying mysql databases – Anton Duzenko Feb 22 '23 at 11:43
5

Note, I've found that method doesn't work on an older version of sudo, specifically "Sudo version 1.6.7p5":

$ echo "<your_password>" | sudo -S -k whoami

Where as this method does work on older and new versions sudo:

$ echo "<your_password>" | sudo -S -v
$ sudo whoami
  • This is **not** an answer to the original question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient [reputation](http://superuser.com/help/whats-reputation) you will be able to [comment on any post](http://superuser.com/help/privileges/comment). – DavidPostill Dec 08 '14 at 15:25
  • @Darren DeHaven : Could you please explain how this become answer for the question asked here? – Renju Chandran chingath Dec 08 '14 at 15:50
3

If you want to take more care, you could make a script, change the permissions of the file so only root can read and edit and then just run it.

Example:
1) Create a file:

gedit ~/.easy.install  

2) Paste this and save:

./configure && make && echo <password> | sudo -S make install && halt  

3) Make it executable:

sudo chmod +x ~/.easy.install  

4) Change the permissions of the file so only root can read and edit it:

sudo chmod 700 ~/.easy.install  

5) Run:

~/.easy.install  

Enjoy ;-)

desgua
  • 103
  • 9
  • 2
    echo will still show up in the process list and if someone gets lucky with ps aux at the exact right moment, they can see the password in clear text. Better to save the password to a file and use < to redirect from the file into sudo. – bobpaul Apr 18 '18 at 17:26
1

In many situation you wouldn't want to pipe the password, but to keep sudo credentials refreshed:

refreshPermissions () {
    local pid="${1}"

    while kill -0 "${pid}" 2> /dev/null; do
        sudo -v
        sleep 10
    done
}

refreshPermissions "$$" &

Then if a command needs root permissions within your program just do:

sudo [command]

And no password will be requested.

1

Setting up sudo like that is dangerous if someone happened to see the fact that sudo requires no password on your account. Unless you know what you are doing, don't do that. I've had it happen at my local A+ Training program with my experimental computer one too many times... -_-

What John T. said sounds good though, except there still is the risk of finding the password in shell history. What CarlF said sounds better, but if one command fails, the computer will still be running with superuser privileges.

TimE.
  • 11
  • 1
0

The problem is resolved. For example, to the user root:

echo -e 'password\npassword\n' | sudo passwd root
0

Personally I do quite the same as John T answered on Nov 9 '09 at 2:47, I've also improved mine according to guidance of his answer, thanks.

Difference is that I tend make use of variables, something like:

AutoSuDo=$" $echo pass | sudo -S";
# Change AutoSuDo to something else.
# Note that string starts with space,
# useful only if used as first command in line

In that way I can easily use mine variable instead of sudo,

$AutoSuDo apt-get update;

That comes quite handy with some longer scripts. I mainly make use of these for personal computers of others, that I have to maintain.

I also recommend to pay attention on:

  • desgua answer on Apr 19 '11 at 23:56
  • user224306 comment on May 14 '13 at 17:38 for John T answer on Nov 9 '09 at 2:47
Janar
  • 33
  • 4