log file reopen should pass opened fd from master process

[Tiziano Müller]

When starting nginx all the log files (error_log, access_log) are created and opened by the master process and the filehandles passed to the worker while forking.

On SIGUSR1 the master reopens the files, chown's them and then the worker reopens the files himself. This has several drawbacks:

• It is inconsistent behaviour and rather surprising (sudden change of ownership upon signal). If you really want to do it this way you should chown the files from the very beginning.
• It permits the unprivileged nginx user read and write access to the current log files which is bad from the security perspective since the unprivileged user also needs to be able to change into/read the log directory

A better solution may be to reopen the log files in the master process as currently done and then use the already available ngx_{read,write}_channel functions to pass the new filehandles down to the worker.

[Maxim Dounin]

Current behaviour is as follows:

• Do not attempt to do anything with logs ownership/permissions on normal startup.
• Chown logs to a user nginx is configured to run workers on logfile quick reopen signal (USR1).

This allows to use any permissions desired as long as logfile quick reopen isn't used (e.g., full configuration reload is used instead), and ensures logfile quick reopen works as currently implemented. While ownership change after USR1 might be a bit surprising for unfamiliar users, it is believed to be better than unconditional ownership change in any case. The need of execute bit on a log directory doesn't looks like a problem, too (note that read access isn't needed). If you are paranoid enough, you can use full configuration reload instead.

On the other hand, passing opened file descriptors from a master process is certainly better approach on platforms which support it, mostly because it needs less configuration. It is planned enhancement for a long time, let this ticket sit in trac as a reminder.