> 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 ?
So it seems to me like introducing a behavior that's variable on a
sysctl parameter doesn't really rationalize things.
Either way, considering the original cause of the bug here, setting log
permissions once in postinst is probably too brittle, confusing and
error-prone. It seems better to set them when the logs are written and
rotated in /etc/init.d/bootlogs; whatever default permissions are used,
that's something that admins can better understand and edit too.
/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.
--
Pierre Ynard
