Opened 12 years ago

Last modified 10 years ago

#165 accepted enhancement

Nginx worker processes don't seem to have the right group permissions

Reported by: Owned by: somebody
Priority: minor Milestone:
Component: nginx-core Version: 1.0.x
Keywords: permissions socket Cc:
uname -a: Debian 6 Squeeze GNU/Linux 2.6.32-5-amd64 x86_64
nginx -V: nginx version: nginx/1.2.0
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx/ --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/ --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6


Package: nginx
Version: 1.2.0-1~squeeze (from Nginx repository, Debian version)

When a UNIX domain socket permissions are set to allow the primary group of the nginx worker processes to read/write on it, the Nginx worker process fail to access it with a 'permission denied' error logged.

Way to reproduce it: Binding Nginx on PHP-FPM UNIX domain socket

PHP-FPM socket configured as follow:

  • User: www-data
  • Group: www-data
  • Mode: 0660

Nginx configured as follow:

  • Worker processes spawned with the user 'nginx'
  • User 'nginx' has 'www-data' as primary group

Details on the configuration can be found here:,226182

It would be also nice to check than any group of the Nginx worker processes can be used for setting access permissions on sockets, not only its primary one.

Change History (2)

comment:1 by Maxim Dounin, 12 years ago

Priority: majorminor
Status: newaccepted
Type: defectenhancement

While the current behaviour is unambigously defined in the documentation, it indeed looks non-intuitive. It would be fine to use primary group of a user specified if group is omitted in the "user" directive.

comment:2 by, 10 years ago

Pinging as recommended by Maxim.

It looks indeed strange not to use the system nginx user primary group and instead force the 'nginx' group when none has been defined through the user directive.

Note: See TracTickets for help on using tickets.