Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1683388 - Log file ownership created by logrotate inconsistent with the one created by systemd
Summary: Log file ownership created by logrotate inconsistent with the one created by ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: nginx
Version: epel7
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Felix Kaechele
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1390183 1390184
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-26 18:52 UTC by Yanick Girouard
Modified: 2021-04-30 00:54 UTC (History)
11 users (show)

Fixed In Version: nginx-1.20.0-2.fc33 nginx-1.20.0-2.fc32 nginx-1.20.0-2.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-04-29 00:57:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Yanick Girouard 2019-02-26 18:52:56 UTC
Description of problem:

When starting the nginx service via systemd using the provided unit file, the log files created in /var/log/nginx are owned by root:root, even though the log directory is owned by nginx:nginx (mode: 700). However, the default logrotate config (/etc/logrotate.d/nginx) that comes with the nginx package creates log files as nginx:nginx and then sends a signal to nginx's process to reopen the logs as the nginx user like so:

postrotate
        /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
endscript


Therefore, the ownership of the /var/log/nginx directory cannot be changed to a user other than nginx or else logrotate will fail to reopen the logs as the nginx user, and show this in the error.log:

... [emerg] 31850#0: open() "/var/log/nginx/error.log" failed (13: Permission denied)
... [emerg] 31850#0: open() "/var/log/nginx/access.log" failed (13: Permission denied)

The service will still work fine if you just started it with systemctl since the logs are then opened as root.

At best, both systemctl and logrotate should create and open the log files with the same ownership and same user.

Version-Release number of selected component (if applicable):

Tested with nginx-1.12.2-2.el7.x86_64, but did not validate with previous versions.


How reproducible:

Very easily.

Steps to Reproduce:
1. Install the epel/x86_64 yum repository
2. Install nginx package
3. Check ownership of /var/log/nginx (should be mode 700/nginx:nginx)
4. Execute: systemctl start nginx
5. Check ownership of log files in /var/log/nginx (should be mode 644/root:root)
6. Execute: curl -I http://localhost at least once
7. Confirm it works. Should get a response and the access.log file should contain lines confirming your access.
8. Change the ownership of the /var/log/nginx directory to a user other than nginx (could be any)
9. Execute: systemctl restart nginx
10. Run steps 6-7 again, and confirm it still works
11. Force a log rotation: logrorate -f /etc/logrotate.d/nginx -v
12. Check the log files in /var/log/nginx. You should see new log files owned by nginx:nginx, and the error.log file should contain the lines mentioned in the description confirming the nginx user is unable to open the files.
13. Execute the curl commands again and confirm it still works, but no logs are created anymore.
14. Change the ownership of /var/log/nginx back to the nginx user
15. Force a log rotation again and confirm that it was able to (new error.log file should be empty and if you execute curl again you should see entries in acess.log)


Actual results:

(See above)

Expected results:

(See above)

Additional info:

N/A

Comment 1 Yanick Girouard 2019-02-26 18:58:49 UTC
Correction, step 11 of reproduction steps should read:

Force a log rotation: logrotate -f /etc/logrotate.d/nginx -v

Comment 2 Felix Kaechele 2020-05-17 03:14:42 UTC
I'll fix this in the next release.

Comment 3 Fedora Update System 2021-04-21 17:02:35 UTC
FEDORA-2021-10c1cd4cba has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-10c1cd4cba

Comment 4 Fedora Update System 2021-04-21 17:02:53 UTC
FEDORA-2021-1556d440ba has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1556d440ba

Comment 5 Fedora Update System 2021-04-21 17:03:11 UTC
FEDORA-2021-3aa9ac7fd1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3aa9ac7fd1

Comment 6 Fedora Update System 2021-04-21 21:51:42 UTC
FEDORA-2021-1556d440ba has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-1556d440ba`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1556d440ba

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2021-04-21 22:01:55 UTC
FEDORA-2021-10c1cd4cba has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-10c1cd4cba`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-10c1cd4cba

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2021-04-22 18:24:26 UTC
FEDORA-2021-3aa9ac7fd1 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3aa9ac7fd1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3aa9ac7fd1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2021-04-29 00:57:21 UTC
FEDORA-2021-10c1cd4cba has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2021-04-29 01:22:03 UTC
FEDORA-2021-1556d440ba has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Fedora Update System 2021-04-30 00:54:52 UTC
FEDORA-2021-3aa9ac7fd1 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.