No reference yet other than locked RH bug referenced in release notes: https://github.com/logrotate/logrotate/releases/tag/3.20.0. https://bugzilla.redhat.com/CVE-2022-1348.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5f19c9604ac3e7b61ff979add45c7db2f037c03 commit e5f19c9604ac3e7b61ff979add45c7db2f037c03 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-05-25 07:46:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-25 07:55:22 +0000 app-admin/logrotate: add 3.20.0 Bug: https://bugs.gentoo.org/847382 Signed-off-by: Sam James <sam@gentoo.org> app-admin/logrotate/Manifest | 2 + app-admin/logrotate/logrotate-3.20.0.ebuild | 95 +++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=898643725ad24e41d3846092d639903f86d3b613 commit 898643725ad24e41d3846092d639903f86d3b613 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-05-25 22:46:15 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-25 22:46:37 +0000 app-admin/logrotate: add 3.20.1 Additional fix to the original security issue. Bug: https://bugs.gentoo.org/847382 Signed-off-by: Sam James <sam@gentoo.org> app-admin/logrotate/Manifest | 2 + app-admin/logrotate/logrotate-3.20.1.ebuild | 95 +++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+)
Since updating from app-admin/logrotate-3.19.0 to app-admin/logrotate-3.20.1, i receive emails with error: state file /var/lib/misc/logrotate.status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition... This seems to happen on all servers that did this update. Shouldn't 3.20.x be 'the fix' to this problem ?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f22a1ea1d23806ba35b1fe2b4c7772819d1bb776 commit f22a1ea1d23806ba35b1fe2b4c7772819d1bb776 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-06-07 01:30:45 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-06-07 01:30:45 +0000 app-admin/logrotate: backport log setting tweaks Should make things a bit less noisy w/ recent CVE fix. Bug: https://bugs.gentoo.org/847382 Signed-off-by: Sam James <sam@gentoo.org> .../files/logrotate-3.20.1-log-changes.patch | 147 +++++++++++++++++++++ app-admin/logrotate/logrotate-3.20.1-r1.ebuild | 96 ++++++++++++++ 2 files changed, 243 insertions(+)
The backported patch will only replace the "error:" prefix with "warning:" in the diagnostic message. But the message will still be printed when logrotate is triggered for the first time after an update from <app-admin/logrotate-3.20.0. The subsequent runs should be silent though. If it is not the case, we rather need to fix the code that handles permissions of the state file.
(In reply to Kamil Dudka from comment #5) > The backported patch will only replace the "error:" prefix with "warning:" > in the diagnostic message. But the message will still be printed when > logrotate is triggered for the first time after an update from > <app-admin/logrotate-3.20.0. The subsequent runs should be silent though. > If it is not the case, we rather need to fix the code that handles > permissions of the state file. That's exactly what I expected them to do? You're saying if they don't do that, we'll need to adapt it? Of course, if people continue to report problems, we'll deal with it...?
I'm sorry, I get your point now. I'd misunderstood that the log level change affected the noise.
No worries. The backported commits can only improve the situation. I just wanted to say that, if the disruptive messages appear more than once on a single system, there must be a deeper problem somewhere that we as logrotate upstream should look at.
Plesae cleanup
