Package: logrotate Version: 3.18.0-2+deb11u1 Severity: normal User: [email protected] Usertags: origin-kali
Dear Maintainer, this bug affects Debian bullseye (ie. logrotate 3.18). It was fixed upstream in version 3.19. The command 'logrotate --state /dev/null ...' happily replaces the device /dev/null with a regular file, breaking the system badly, in a non-obvious way. Steps to reproduce: # ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Jun 29 01:43 /dev/null # logrotate --state /dev/null /etc/logrotate.conf # ls -l /dev/null -rw-rw--w- 1 root root 1257 Jun 29 02:19 /dev/null Steps to recover: # rm -f /dev/null; mknod -m 0666 /dev/null c 1 3 I looked at the 'bullseye' branch of the Salsa repo [1], I've seen that you imported a number of patches related to the state file. In particular, the patch Do-not-lock-state-file-dev-null.patch is what lead me to shot myself in the foot, since it adds two lines in the manual page, suggesting to use /dev/null as a state file: ++If \fI/dev/null\fR is given as the state file, then \fBlogrotate\fR will ++not try to lock or write the state file. However, in your series of upstream patches, I think you missed this one: https://github.com/logrotate/logrotate/commit/45669264 Given the potential for destruction of 'logrotate -s /dev/null', and seeing how simple is the patch above, would you consider doing an upload to fix it in bullseye? Best, Arnaud ---- [1] https://salsa.debian.org/debian/logrotate/-/tree/bullseye
