Configurable Log File Permissions for access.log and error.log

Describe the feature you'd like to add to nginx

Currently, the file permissions for access.log and error.log in NGINX are hardcoded. When these log files are created at service startup (if they do not already exist), they default to permissions of 644. This setup can be limiting, as many use cases require different levels of access and permissions for log files, especially in environments with strict security or compliance requirements.

Describe the problem this feature solves

In the current implementation of NGINX, the permissions for log files, such as access.log and error.log, are set to a hardcoded constant value NGX_FILE_DEFAULT_ACCESS. This value, defined as 0644, is directly applied when log files are created. The relevant code can be seen in ngx_log.c at lines 376-378, where NGX_FILE_DEFAULT_ACCESS is passed as the mode for log file creation.

This hardcoded permission setting poses a challenge in environments where custom permissions are needed for security or compliance reasons. Since NGX_FILE_DEFAULT_ACCESS is seemingly set before the nginx.conf configuration file is parsed, users currently have no way to configure custom permissions through standard NGINX settings. As a result, they must rely on external scripts or automation to modify the permissions after the log files are created, which adds complexity and reduces flexibility.

Additional context

Desired Solution
To address this issue, it would be helpful to make NGX_FILE_DEFAULT_ACCESS configurable in a way that aligns with the startup process of NGINX. Since these files are created before nginx.conf is parsed, we would need a solution that allows for custom permissions to be set early in the startup process, ideally through an approach the NGINX developers recommend.

Start with src/core/ngx_log.c at lines 376-378 and trace when access.log and error.log are created relative to nginx.conf parsing. Determine how configurable permissions could be supplied early in startup without relying on post-creation scripts. Done means the default behavior remains understood and users have a documented way to set custom log-file permissions.