I have found that when sending USR1 signal to Nginx that Nginx chowns
the log files even if log files already exist and are already writable
(but have different user/group). Let me elaborate on the situation:
Nginx runs as www-data for its user/group, in a virtual hosting
environment. I use Webmin/Virtualmin to create the logs, and handle log
rotation in an automated manner. Log files exist like follows:
-rw-rw---- 1 domain1 www-data 0 Oct 18 11:06
domain1.com_access_log
-rw-rw---- 1 domain1 www-data 0 Oct 18 11:06 domain1.com_error_log
-rw-rw---- 1 domain2 www-data 0 Oct 18 11:19
domain2.org_access_log
-rw-rw---- 1 domain2 www-data 0 Oct 18 11:19 domain2.org_error_logThese are located centrally and then symlinked to from the domain user’s
home folder. Now, for instance, AWStats runs for each domain user,
under the domain user’s user/group. This works just fine, for now.
Now, the logrotate script for each domain rotates the files, creating a
new, empty file with the same permissions and owner/group. But if I
send a post-logrotate USR1 signal to Nginx, it will chown the log files
to www-data/www-data, even though it does not need to, since the
files are already writable given that the log files maintain their 0660
permissions, and are in the www-data group. I of course can not
feasibly chown these log files back manually, or even in an automated
way, and elevated run permissions (have to jump all the way to root) for
AWStats are out of the question. The problem then is that once Nginx
chowns the log files to www-data/www-data, the domain user can no longer
read/write these files for anything.
I think that Nginx should first test for log file existence, then if so,
test for writability. Then, if the log file is already writable, NOT
chown the log file, as there is no point. It is of course not as simple
as checking that either user or group match with Nginx user/group, since
in my case www-data has all domain user groups as secondary groups, so
technically the log files do not even need the www-data group
(domain2/domain2 would work just fine).
Anyway, it seemed that Nginx sometimes needlessly chowns the log files,
and was wondering if this was intentional, an oversight, or an outright
bug that should be fixed. For one, this bug then is only present when
log files are kept at 0660 or higher. I would think fixing it would not
affect any people negatively, unless of course they have made the
assumption that the log files will be chowned. If there are in fact any
reasons that Nginx must always chown the log files, even if they are
already writable under their current pemissions/ownership, I would like
to know as well (so I can better my understanding of Nginx :))
Thank you
Posted at Nginx Forum: