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.
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 tosudoers
will maintain thesudo
securities; but allow a particular user to run the script with elevated permissions and no password.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.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.