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!

Hi,

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

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`)?

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

?

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

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