Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

Dmitry Bogatov KAction at debian.org
Tue Feb 5 16:15:45 GMT 2019

control: tags -1 +moreinfo
control: user KAction at gnu.org
control: usertags -1 objections

[2019-02-04 07:58] Pierre Ynard <linkfanel at yahoo.fr>
> > Why are you skeptical? I do not see, how syncing /var/log/dmesg
> > permissions with kernel.dmesg_restrict could break things. Or am I
> > missing something?
> Well, /var/log/dmesg only covers bootup kernel logs, so maybe some admin
> set it up for unprivileged use of bootup logs, but still wants kernel
> logs in general and after bootup to be restricted, to help deter local
> exploits for example.
> /var/log/kern.log permissions don't depend on kernel.dmesg_restrict.
> Also rsyslog seems to capture to kern.log just as many early logs as
> /var/log/dmesg?

While this is defintely interesting question, let us focus on what we
can control -- initscripts.

> /var/log/dmesg isn't the only log file whose permissions are set in that
> brittle way in postinst. Others are /var/log/fsck/{checkroot,checkfs}
> (the two logsave ones), and /var/log/boot (bootlogd). The same logic
> applies so it could make sense to change these too. Or any others making
> use of logsave like was suggested in #901289. Except that there isn't a
> relevant sysctl variable for those.
> The way I look at it is as a whole, how initscripts provides logging
> functionality outside of syslog while it may not be available or suited,
> and how to manage that and log permissions. I agree that looking
> at kernel.dmesg_restrict can be a cool tradeoff, but that's very
> specialized.

Thank you for your explanation. Let me sum it up. We have following options:

 * sync permissions of `kernel.dmesg_restrict' and /var/log/dmesg, leave
   other log files (/var/log/boot, ...) as-is

 * enforce permissions of all log files (dmsg, boot, ...) to specific
   value 640 root:adm.

 * sync permissions of all log files (dmsg, boot, ...) to

 * status-quo, when permissions are set in postinst, but are not enforced
   by initscripts.

As I understand situation, I favor second option. So question is would
anybody be unhappy, if initscripts will override manual `chown/chmod' on
logs, created by initscripts.
        Note, that I send and fetch email in batch, once every 24 hours.
                 If matter is urgent, try https://t.me/kaction

More information about the Debian-init-diversity mailing list