2

I am trying to script a non-interactive install of Meteor (JS Framework) and part of the script prompts for sudo . I cant seem to get past it w/ my scripting skills.

The install is : curl https://install.meteor.com | /bin/sh

At a later point in the script it prompts for Sudo password. I want this step to fail. And then I can script my way around the resolution .

Note:: I cannot add the user to sudoers file, its running in a shared environment that doesnt allow my user elevated access.

5
  • You could obviate sudo by configuring it with a line like: # allow script-user to run my-script as user user-with-permissions script-user ALL = (user-with-permissions) NOPASSWD: /usr/local/bin/scripts/my-script Adding a line like that to sudoers will maintain the sudo securities; but allow a particular user to run the script with elevated permissions and no password.
    – ericx
    Commented Aug 8, 2014 at 19:40
  • 1
    @ericx OP: I cannot add the user to sudoers file, its running in a shared environment that doesnt allow my user elevated access. Besides which, modifying /etc/sudoers for a one-off install script, and adding that one-off install script to /usr/local/bin seems like overkill given the issue. Especially since we don't know exactly what the OP is trying to do; if he wants to do a local user install inside a chroot jail, not only would that be overkill, it wouldn't work. Commented Aug 8, 2014 at 19:52
  • 2
    Most linux programs that read a password (like sudo and ssh) don't read the password from STDIN but instead open /dev/tty directly. This way you can't pipe the password into it. If you detach the process from the controlling terminal then /dev/tty will be invalid and reading from it will fail. Programs like daemon can do this. Commented Aug 10, 2014 at 0:11
  • @AdrianPronk I like the way you think, sir. Commented Aug 10, 2014 at 15:29
  • @AdrianPronk that is an interesting fact.
    – Mike Graf
    Commented Aug 11, 2014 at 17:11

2 Answers 2

10

This will replace any instance of the string "sudo" (sans quotes) with "sudo -n" (sans quotes):

curl https://install.meteor.com | sed 's/sudo/sudo -n/g' | /bin/sh

From the sudo manpage:

-n' The -n (non-interactive) option prevents sudo from prompting the user for a password. If a password is required for the command to run, sudo will display an error message and exit.

It's worth pointing out, however, that this only works if you would be prompted for a password. In other words, if you've recently run sudo, and those credentials allow you to run sudo without entering a password for 15 minutes (the default) and you run this within 15 minutes, the above command will still succeed in running sudo. Or if you are never normally prompted for a password, that will also cause success.

To invalidate the session created by recently entering sudo credentials, run sudo -k. Again, from the manual:

-k [command]

When used alone, the -k (kill) option to sudo invalidates the user's cached credentials. The next time sudo is run a password will be required. This option does not require a password and was added to allow a user to revoke sudo permissions from a .logout file. Not all security policies support credential caching.

When used in conjunction with a command or an option that may require a password, the -k option will cause sudo to ignore the user's cached credentials. As a result, sudo will prompt for a password (if one is required by the security policy) and will not update the user's cached credentials.

If that doesn't work for you (if, for example, your security policy wouldn't request a password), you can try:

curl https://install.meteor.com | sed 's/sudo/sudo \/bin\/false/g' | /bin/sh

If the program sudo was running failed, sudo will fail. And from the manpage for false:

Exit with a status code indicating failure.

...is all false does.

What this means is that, instead of running whatever command it's trying to run with sudo, it will instead run /bin/false, passing the name of the original program intended to be run under sudo as the first argument.

NOTE: If you actually want the entire first line containing a sudo call to fail, these solutions won't (necessarily) make that happen. The sudo call itself will fail, but if its arguments are created in a subshell, or there are previous commands on the same line, those will work as usual. So, if the original command were:

sudo exterminate "$(ls /humans)"

That would become:

sudo /bin/false exterminate "$(ls /humans)"

And ls /humans would still run. Probably obvious, and it likely doesn't matter, but just in case, I thought I'd mention.

3
  • we have a winner.
    – Mike Graf
    Commented Aug 11, 2014 at 17:07
  • 1
    for the record, I ended up using an expect script that puts in an empty string 3 times, eventually failing out. I will upgrade to this better way.
    – Mike Graf
    Commented Aug 11, 2014 at 17:08
  • @MikeGraf Ahh! Expect! Despite the fact that I have been mocked for liking it (as its manpage is... a bit dated... For example, here are some things Expect can do: Cause your computer to dial you back, so that you can login without paying for the call.), it's a fine language. Commented Aug 11, 2014 at 17:11
0

Why not modify the script before using it : curl https://install.meteor.com > /tmp/script, modify it in /tmp/script, then run it /bin/sh /tmp/script

Edit: Or if the password is asked, just type three times a bad password and you will be rejected

1
  • it has to be non-interactive
    – Mike Graf
    Commented Aug 8, 2014 at 18:55

You must log in to answer this question.

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