Package: logrotate
Version: 3.18.0-2+deb11u1
Severity: normal
X-Debbugs-Cc: [email protected]
affects: release.debian.org
Dear Maintainer,
after the bullseye 11.4 point release I started to see the following mails
from logcheck:
Jul 10 00:00:24 mainframe logrotate[37314]: error: state file /var/lib/logrotate/status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
I suspect the severity of this bug should be higher, but I will leave this to
you.
Thanks for maintaining logrotate!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
So what CAN we actually do? Well, individual decisions (eating less meat,
taking public transport, buying less fast fashion) are all important, but we
also need to change the system. As you may know, just 100 companies are
responsible for 71% of global emissions. (@JessicaTheLaw)
https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change
Acknowledgement sent
to Salvatore Bonaccorso <[email protected]>:
Extra info received and forwarded to list. Copy sent to Christian Göttsche <[email protected]>.
(Sun, 10 Jul 2022 07:45:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1014659: logrotate: error: state file
/var/lib/logrotate/status is world-readable
Date: Sun, 10 Jul 2022 09:38:37 +0200
Hi,
On Sun, Jul 10, 2022 at 01:35:50AM +0200, Holger Levsen wrote:
> Package: logrotate
> Version: 3.18.0-2+deb11u1
> Severity: normal
> X-Debbugs-Cc: [email protected]
> affects: release.debian.org
>
> Dear Maintainer,
>
> after the bullseye 11.4 point release I started to see the following mails
> from logcheck:
>
> Jul 10 00:00:24 mainframe logrotate[37314]: error: state file /var/lib/logrotate/status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
>
> I suspect the severity of this bug should be higher, but I will leave this to
> you.
>
> Thanks for maintaining logrotate!
There is https://security-tracker.debian.org/tracker/CVE-2022-1348
fixed in the logrotate update landed in bullseye 11.4. In fact if the
state file is world-readable logrotate will error out as per
https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9
I wonder if the packaging should adjust the permissions as well on the
state file on update? (which technically not part of the fix, if the
state file is not present it is created correctly with 0640
permissions, but a present one should be adjusted?).
Regards,
Salvatore
Acknowledgement sent
to Christian Göttsche <[email protected]>:
Extra info received and forwarded to list.
(Sun, 10 Jul 2022 09:42:06 GMT) (full text, mbox, link).
Subject: Re: Bug#1014659: logrotate: error: state file /var/lib/logrotate/status
is world-readable
Date: Sun, 10 Jul 2022 11:38:02 +0200
On Sun, Jul 10, 2022 at 01:35:50AM +0200, Holger Levsen wrote:
> after the bullseye 11.4 point release I started to see the following mails
> from logcheck:
>
> Jul 10 00:00:24 mainframe logrotate[37314]: error: state file /var/lib/logrotate/status is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
Does this only happen for the first logrotate invocation after the
update or continuously?
If continuously what are the permissions of the state file (`ls -l
/var/lib/logrotate/status`)?
On Sun, 10 Jul 2022 at 09:45, Salvatore Bonaccorso <[email protected]> wrote:
>
> I wonder if the packaging should adjust the permissions as well on the
> state file on update? (which technically not part of the fix, if the
> state file is not present it is created correctly with 0640
> permissions, but a present one should be adjusted?).
Something like the following in postinst:
if [ -f /var/lib/logrotate/status ]; then
mv /var/lib/logrotate/status /var/lib/logrotate/status.old
install -m 0640 /var/lib/logrotate/status.old /var/lib/logrotate/status
fi
?
Acknowledgement sent
to Roman Mamedov <[email protected]>:
Extra info received and forwarded to list. Copy sent to Christian Göttsche <[email protected]>.
(Sun, 10 Jul 2022 11:24:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1014659: logrotate: error: state file
/var/lib/logrotate/status is world-readable
Date: Sun, 10 Jul 2022 16:15:36 +0500
Hello,
Here is the permission layout after the "error" message has been issued. I did
not check what it was before. I'm not sure if this means I will not get
another "error" tomorrow. On another host, I did "chmod o-rx" on the logrotate
directory, thinking maybe it wants that. Not sure yet if that helped either.
# ls -la /var/lib/logrotate/
total 12
drwxr-xr-x 2 root root 4096 Jul 10 06:32 .
drwxr-xr-x 29 root root 4096 Jun 22 13:44 ..
-rw-r----- 1 root root 782 Jul 10 06:32 status
--
With respect,
Roman
Acknowledgement sent
to "McIntyre, Vincent (S&A, Marsfield)" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Christian Göttsche <[email protected]>.
(Sun, 17 Jul 2022 23:51:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1014659: logrotate: error: state file
/var/lib/logrotate/status is world-readable
Date: Sun, 17 Jul 2022 23:41:19 +0000
I am seeing this issue as well.
In particular I see it with a state file that, when I check,
is mode 0640. e.g.
error: state file /var/log/rsync/.logrotate.status.rsync_ is world-readable
and thus can be locked from other unprivileged users.
Skipping lock acquisition..
These are the state and config files
-rw-r----- 1 root root 145 Jul 18 01:30 .logrotate.status.rsync_
-rw-r--r-- 1 root root 162 Apr 25 02:30 .logrotate.conf.rsync_
But when I try to reproduce the issue (below), it goes away.
testbox-142% ls -al
total 1912
4 drwx------ 3 joe staff 4096 Jul 18 09:13 ./
4 drwxrwxrwt 6 root root 4096 Jul 18 09:08 ../
4 -rw-r--r-- 1 joe staff 212 Jul 18 09:08 conf
4 -rw-r----- 1 joe staff 71 Jul 18 09:10 state.groupread
4 -rw------- 1 joe staff 112 Jul 18 09:12 state.ownerread
4 -rw-r--r-- 1 joe staff 112 Jul 18 09:13 state.worldread
1884 -rw-r--r-- 1 joe staff 1925683 Jul 18 02:02 test.log
% cat conf
/var/tmp/test/test.log {
missingok
create 0644
compress
daily
rotate 7
# log will be rotated when larger than this,
# but only if the minimum time interval has passed
minsize 5M
}
% /usr/sbin/logrotate -v -s state.worldread conf
reading config file conf
error: state file state.worldread is world-readable and thus can be locked from other unprivileged users. Skipping lock acquisition...
Reading state from file: state.worldread
Allocating hash table for state file, size 64 entries
Creating new state
Handling 1 logs
rotating pattern: /var/tmp/test/test.log after 1 days (7 rotations)
empty log files are rotated, only log files >= 5242880 bytes are rotated, old logs are removed
considering log /var/tmp/test/test.log
Creating new state
Now: 2022-07-18 09:13
Last rotated at 2022-07-18 09:00
log does not need rotating (log has already been rotated)
% /usr/sbin/logrotate -v -s state.groupread conf
reading config file conf
Reading state from file: state.groupread
Allocating hash table for state file, size 64 entries
Creating new state
Handling 1 logs
rotating pattern: /var/tmp/test/test.log after 1 days (7 rotations)
empty log files are rotated, only log files >= 5242880 bytes are rotated, old logs are removed
considering log /var/tmp/test/test.log
Creating new state
Now: 2022-07-18 09:14
Last rotated at 2022-07-18 09:00
log does not need rotating (log has already been rotated)
% /usr/sbin/logrotate -v -s state.ownerread conf
reading config file conf
Reading state from file: state.ownerread
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Handling 1 logs
rotating pattern: /var/tmp/test/test.log after 1 days (7 rotations)
empty log files are rotated, only log files >= 5242880 bytes are rotated, old logs are removed
considering log /var/tmp/test/test.log
Now: 2022-07-18 09:15
Last rotated at 2022-07-18 09:00
log does not need rotating (log has already been rotated)
% cat state.worldread
logrotate state -- version 2
"/var/tmp/test//test.log" 2022-2-21-2:0:0
"/var/tmp/test/test.log" 2022-7-18-9:0:0
% cat state.groupread
logrotate state -- version 2
"/var/tmp/test//test.log" 2022-2-21-2:0:0
"/var/tmp/test/test.log" 2022-7-18-9:0:0
% cat state.ownerread
logrotate state -- version 2
"/var/tmp/test//test.log" 2022-2-21-2:0:0
"/var/tmp/test/test.log" 2022-7-18-9:0:0
At this point I discovered that rotatelog changes the world-readable
state file to mode 0640, so a subsequent run works ok.
% /usr/sbin/logrotate -v -s state.worldread conf
reading config file conf
Reading state from file: state.worldread
Allocating hash table for state file, size 64 entries
Creating new state
Handling 1 logs
rotating pattern: /var/tmp/test/test.log after 1 days (7 rotations)
empty log files are rotated, only log files >= 5242880 bytes are rotated, old logs are removed
considering log /var/tmp/test/test.log
Now: 2022-07-18 09:24
Last rotated at 2022-07-18 09:00
log does not need rotating (log has already been rotated)
I edited away the lines with double slash (//) entry and tested
again, that didn't seem to make a difference.
% cat state.worldread
logrotate state -- version 2
"/var/tmp/test/test.log" 2022-7-18-9:0:0
% cat state.groupread
logrotate state -- version 2
"/var/tmp/test/test.log" 2022-7-18-9:0:0
% cat state.ownerread
logrotate state -- version 2
"/var/tmp/test/test.log" 2022-7-18-9:0:0
I think it would be helpful if rotatelog printed a message that
it was forcibly changing the state file permissions. Otherwise
the only way to resolve the confusion is a series of tests such
as I have shown here.
Vince
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.