logrotate-3.18.1-3.fc35.x86_64 logrotate[2151]: error: state file /var/lib/logrotate/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition... besides i din't set that permissions anywhere the message is full nonsense how is a unprivileged user supposed to change a root-owned file with 640? and instead log such nonsense and break or whatever just "chmod 600>" the damend file and leave me in peace on dozens of machines [root@buildserver:~]$ stat /var/lib/logrotate/logrotate.status File: /var/lib/logrotate/logrotate.status Size: 1509 Blocks: 8 IO Block: 4096 regular file Device: 811h/2065d Inode: 32776 Links: 1 Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2022-05-27 00:33:00.771369415 +0200 Modify: 2022-05-27 00:33:00.771369415 +0200 Change: 2022-05-27 00:33:00.772369433 +0200 Birth: 2022-05-27 00:33:00.771369415 +0200
This looks as CVE-2022-1348. If that is the case here are the patches, fixed in 3.20.0: - https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9 - https://github.com/logrotate/logrotate/commit/addbd293242b0b78aa54f054e6c1d249451f137d
(In reply to Harald Reindl from comment #0) > logrotate-3.18.1-3.fc35.x86_64 > > logrotate[2151]: error: state file /var/lib/logrotate/logrotate.status is > world-readable and thus can be locked from other unprivileged users. > Skipping lock acquisition... > > besides i din't set that permissions anywhere the message is full nonsense > how is a unprivileged user supposed to change a root-owned file with 640? The state file used to have permissions 0644, which was problematic. You are right that only owner (usually root) could change the file. But anybody else was able to _lock_ the file using flock(1). If the file is owned by root/root and has permission 0640, there is no problem there and the warning is not printed. > and instead log such nonsense and break or whatever just "chmod 600>" > the damend file and leave me in peace on dozens of machines This should be harmless. If you do not chmod the state file, the warning will be printed on the first rotation only. The updated state file will be written with mode 0640, which prevents the warning from being printed in future runs. (In reply to Jan Zizka from comment #1) > This looks as CVE-2022-1348. If that is the case here are the patches, fixed in 3.20.0: > - https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9 > - https://github.com/logrotate/logrotate/commit/addbd293242b0b78aa54f054e6c1d249451f137d To be clear, logrotate-3.18.1-3.fc35 has the patches applied and it is the reason why the warning is printed.
> The updated state file will be written with mode 0640, which prevents the warning from being printed in future runs then for the sake of god don't write "error:" which implies a) not fixed automatically b) operation aborted "warning: changed permissions of /var/lib/logrotate/logrotate.status from 0644 to 0640 because bla" and everything would have been fine - as it's implemented i looked at the permissions and thought "idiots, well then i set it to 600 for you"
(In reply to Kamil Dudka from comment #2) > (In reply to Jan Zizka from comment #1) > > This looks as CVE-2022-1348. If that is the case here are the patches, fixed in 3.20.0: > > - https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9 > > - https://github.com/logrotate/logrotate/commit/addbd293242b0b78aa54f054e6c1d249451f137d > > To be clear, logrotate-3.18.1-3.fc35 has the patches applied and it is the > reason why the warning is printed. Ah yes, sorry I did miss the version. Thanks for clarification!
Good point, "error:" is misleading when it does not affect the exit code. I have opened an upstream pull request to fix it: https://github.com/logrotate/logrotate/pull/448
upstream commit: https://github.com/logrotate/logrotate/commit/31cf1099ab8514dfcae5a980bc77352edd5292f8
Fedora commits: https://src.fedoraproject.org/rpms/logrotate/c/c769cd24bcbd2eea85916734abd47be7c67bbb85?branch=rawhide https://src.fedoraproject.org/rpms/logrotate/c/078aa77b0ff19c2687d89418c8a1438caec17445?branch=f35 https://src.fedoraproject.org/rpms/logrotate/c/36f6a47613fc67b7c9375ba9028a8431fc903eb0?branch=f34
FEDORA-2022-28e51014ed has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-28e51014ed
FEDORA-2022-14f7b1a698 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-14f7b1a698
FEDORA-2022-ff0188b37c has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ff0188b37c
FEDORA-2022-28e51014ed has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-28e51014ed` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-28e51014ed See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-ff0188b37c has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-ff0188b37c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ff0188b37c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-14f7b1a698 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-2022-14f7b1a698` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-14f7b1a698 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-28e51014ed has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-ff0188b37c has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.