I have a home webserver I muck around with, mainly for learning and testing. I use Apache2 on Debian Bullseye.

One of the things I have been playing around with is running Bash scripts from the webserver with php. Some of these scripts require sudo as they do things like kill a users session, or start or stop a virtual server in apache.

The scripts are all outside of the public directories and are owned by a user account, with www-data the group. The permissions are; owner=rwx, group=x, other=nothing.

The www-data user has sudo access with the line

www-data ALL=(root) NOPASSWD: /path/to/scripts.sh

I have read on a few posts that it is a bad idea to give the webserver sudo access, but cant think of a better (safer?) way. I have considered setuid but unsure if this considered a safer alternative.

If I have to run a script with elevated privileges what would be the secure way? Or is sudo with only specific scripts allowed the best way?


  • 1
    If sudo is called within the script then the script group needs r-x permissions. If the script is called via sudo (as the sudoers line indicates) then 700 would be enough. Commented May 6, 2023 at 15:05
  • @HaukeLaging I have changed the mode to 700 now and tested it. Does this work without the execute bit because of the sudo? effectively running it as root and "using" the execute bit that was set for the user?
    – Èl Sea
    Commented May 7, 2023 at 12:51
  • 1
    That is correct. The sudo process runs as root immediately (because it is a SUID root binary) so the interpreter (e.g. bash) runs as root when the file permissions are checked (or not even checked – root). Commented May 7, 2023 at 14:14

2 Answers 2


Giving the web server user (in this case, www-data) sudo access can be a security risk, as it allows any script executed by the web server to potentially execute arbitrary commands with elevated privileges. This can be especially dangerous if the scripts are not properly sanitized and validated, as it can open up the system to command injection and other attacks.

A safer alternative would be to use a more fine-grained approach to granting elevated privileges to specific scripts. For example, instead of giving the web server user sudo access, you could use a tool like sudoers to grant specific users or groups permission to execute specific commands with elevated privileges.

In your case, you have already done this by specifying the exact path to the script and allowing only www-data to execute it with sudo. This is a good approach as it limits the potential for abuse while still allowing the script to perform necessary tasks.

Another option to consider is using a separate process or service to perform tasks that require elevated privileges. For example, you could write a daemon or system service that listens for requests from the web server and executes the necessary commands with elevated privileges. This can help further isolate the privileged tasks from the web server and limit potential security risks.

Overall, it is important to carefully consider the security implications of granting elevated privileges to any user or process, and to use a fine-grained approach to limit potential risks.

Latest advice i can give you that you should look at Selinux configuration for your web-server, you can limit your process syscall by using Selinux.


If the scripts / commands are safely implemented then sudo/SUID is not a problem.

How to create safe scripts/programs is answered in books, not in a Stackexchange response...

In your case it may make sense to consider for each command with elevated privileges whether it really needs root privilege. For example: In order to kill the processes of a user you do not have to be root; it is enough to be that user.

You can enumerate the allowed (or disallowed) users in sudoers or use a wrapper script which checks e.g. if the UID is at least 1000 (assuming that is where the user accounts start).

Restrictions for root processes

You can do a lot to limit the capabilities of processes running as root. The probably easiest approach is to use an (instanciated) Systemd service or systemd-run because then you have easy access to all the protection and limitation limits in man systemd.exec. For example you need only very limited filesystem access and no network access to trigger a webserver reload/restart.

  • Minor nitpick. suid is not an option for bash scripts without mucking around with Linux capacities.
    – doneal24
    Commented May 6, 2023 at 17:41

You must log in to answer this question.

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