Wednesday, June 10, 2015

Nginx processes' users



Many people get confused about user ownership of the nginx processes.

Most people believe that Nginx runs as Root (oh my god) and some others believe that Nginx runs entirely as nobody user.

Now, let's do a distinction between the master and the workers processes.

Master process

The master process runs with the user used to launch the service. Typically root. Why root? Root is generally used in order to be able to bind sockets on ports number below 1024 (privileged ports). In fact unprivileged users cannot bind ports below 1024. 

In general, master process has the following tasks (http://www.aosabook.org/en/nginx.html)


  • reading and validating configuration
  • creating, binding and closing sockets
  • starting, terminating and maintaining the configured number of worker processes
  • reconfiguring without service interruption
  • controlling non-stop binary upgrades (starting new binary and rolling back if necessary)
  • re-opening log files
  • compiling embedded Perl scripts

The fact that the master process starts as root is the result that you actually run with a root account (or otherwise you will have port binding problem). Potentially you could run it with a different user and configure your system to use a port number higher than 1024. This is simple as that.

Common usage anyway(in particular for reverse proxies) is to bind standard HTTP or HTTPS ports like port 80 and or 443. Wouldn't make much sense to have a reverse proxy listening on custom ports. Can be done technically, doesn't make much sense logically.

So, the gold rule here is that the master process belongs to the user which has started/spawned Nginx. Simple as that.

Child Process(es), workers


Child process(es), known as workers, are the actors which actually move your web services. While the master process is pretty much an orchestrator, the workers are the real hero here.

One gold rule of web servers is to grant the minimum access level required to the web server's processes (yes, I am talking to you my developer friend which always uses a chmod 777 approach). Having said this, wouldn't make much sense to run workers as root.

What is the risk? The risk is that if someone breaches your web application or your web server, doesn't need to elevate its account since it is already root. Attackers cannot ask for more! They will love you (and no, they won't have mercy for you!).

Now, the question is, which user is being used by workers? 

The response is simple but a bit more complicated than it seems.


1. If nothing is specified at compile time (configure phase) and nothing is specified at configuration file level, then the used user is "nobody"

2. If a user (and optionally a group) is specified at compile time with the options --user and --group and nothing is specified  in the config file, then the user specified during the build is used

3. If a user (and optionally a group) is specified in the config file, it will be used as owner of the spawned workers


In general, the priority is the following:

- Config file
- Default (nobody if not specified at compile time or the user name specified at compile time)

Note: A common pitfall for newcomers is to specify a user that do not exist (or "nobody" doesn't exist). In this case, remember to add the user before you actually start nginx.



The way nginx operates is the following, on a typical real environment with 3 workers activated:

root     21279  0.0  0.0 109152  4136 ?        Ss   14:37   0:00 nginx: master process /usr/sbin/nginx
nginx    21280  0.0  0.0 109588  5876 ?        S    14:37   0:00  \_ nginx: worker process
nginx    21281  0.0  0.0 109588  5876 ?        S    14:37   0:00  \_ nginx: worker process
nginx    21282  0.0  0.0 109588  5876 ?        S    14:37   0:00  \_ nginx: worker process

Useless to say, to check it, use the ps -auxf command.

This is very similar (in terms of users) of Apache HTTPD server using pre-fork

root     21401  6.5  0.3 417676 24852 ?        Ss   14:39   0:00 /usr/sbin/httpd -DFOREGROUND
apache   21410  0.5  0.1 690288 13748 ?        Sl   14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21411  0.5  0.1 690288 13748 ?        Sl   14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21412  0.5  0.1 690288 13748 ?        Sl   14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21413  0.5  0.1 690288 13748 ?        Sl   14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21414  0.5  0.1 419840 14584 ?        S    14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21415  0.5  0.1 419840 14584 ?        S    14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21416  0.5  0.1 419840 14584 ?        S    14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21417  0.5  0.1 419840 14584 ?        S    14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND
apache   21418  0.5  0.1 419840 14584 ?        S    14:39   0:00  \_ /usr/sbin/httpd -DFOREGROUND


















No comments:

Post a Comment