Ygtjki

I made some scripts containing some functions which by design needs sudo permission. I have added those path in .bashrc for Linux and .bash_profile for MacOS so that it can be called from anywhere.

But I do not want the user to type sudo each time they want to call those script functions. Is there any way I can imply sudo in a way that whenever these functions are called, terminal would assume its being called from root user?

I think I should just add sudo -i at the beginning of the script or maybe each function? Or is there any other alternative way of implying sudo? Also, would be great to know if you think it would be terrible or dangerous to imply sudo and if it is not recommended.

An example of dangerous-function script that contains some functions which, I am trying to accomplish without specifying sudo

#!/bin/bash
start-one()

 ## do dangerous stuff with sudo
 systemctl start dangerous.service


start-two()

 systemctl start dangerous1.service


start-launchwizard()

 systemctl start dangerous2.service


## Calling functions one by one...
"$@"

I dont want to call them by sudo dangerous-function start-one
I just want to call them with dangerous-function start-one but still get the same result as the previous one.

The "$@" will expand to the list of command line arguments, individually quoted. This means that if you call your script with

./script.sh start-one

it will run start-one at that point (which is your function). It also means that invoking it as

./script.sh ls

it would run ls.

Allowing a user to invoke the script using sudo (or using sudo inside the script) would allow them to run any command as root, if they had sudo access. You do not want this.

Instead, you would need to carefully validate the command line arguments. Maybe something like

foo_func () 
 # stuff
 printf 'foo:t%sn' "$@"


bar_func () 
 # stuff
 printf 'bar:t%sn' "$@"


arg=$1
shift

case $arg in
 foo)
 foo_func "$@" ;;
 bar)
 bar_func "$@" ;;
 *)
 printf 'invalid sub-command: %sn' "$arg" >&2
 exit 1
esac

Testing:

$ sh script.sh bar 1 2 3
bar: 1
bar: 2
bar: 3

$ sh script.sh baz
invalid sub-command: baz

This would be safer to use with sudo, but you would still not want to execute anything that the user gives you within your various functions directly without sanitising the input. The script above does this by restricting the user to a particular set of sub-commands, and each function that handles a sub-command does not execute, eval, or source its arguments.

Let me say that again with other words: The script does not, and should not, try to execute the user input as code in any way. It should not try to figure out whether an argument corresponds to a function in the current environment that it can execute (functions may have been put there by the calling environment) and it should not execute scripts whose pathnames were given on the command line etc.

If a script is performing administrative tasks, I would be expecting to have to run it with sudo, and I would not want the script itself to ask me for my password, especially not if it's a script that I may want to run non-interactively (e.g. from a cron job). That is, a script performing administrative tasks requiring root privileges should (IMHO) be able to assume it's running with the correct privileges from the start.

If you want to test this in the script, you could do so with

if [ "$( id -u )" -ne 0 ]; then
 echo 'please run this script as root' >&2
 exit 1
fi

It then moves the decision of how to run the script with root privileges to the user of the script.

You can add your script in /etc/sudoers (preferably using `visudo) so that it is accessible to the user.

user ALL= /path/to/script

Then the user will able to execute path/to/script without sudo.