Hide Forgot
/var/log/nginx is owned by nginx:nginx, but files in there are created/opened as root:root by the supervisory process on startup. This represents a possible privilege escalation from nginx to root. Product Security has rated this as Low security impact (bug 1390182), but a permissions review for future packages is in order. See also: https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html
So far as I can tell this is a product of the nginx design. nginx assumes that unprivileged child processes can open logs as writeable. Note from http://nginx.org/en/docs/control.html - "" Rotating Log-files In order to rotate log files, they need to be renamed first. After that USR1 signal should be sent to the master process. The master process will then re-open all currently open log files and assign them an unprivileged user under which the worker processes are running, as an owner. After successful re-opening, the master process closes all open files and sends the message to worker process to ask them to re-open files. Worker processes also open new files and close old files right away. As a result, old files are almost immediately available for post processing, such as compression. "" There is obviously a trade-off between a less flexible but more secure design for logging (as used by httpd), and a more flexible but less secure as used by nginx. It does not appear that upstream treat this as a bug, so I don't see why we should.
It does not seem to me that the quoted part of the documentation explains why *the directory* should be writable to nginx user. It says that the privileged master process creates log files and chowns them nginx user. That should be enough for worker process to open/write them without needing write access to the directory.