[2019-02-07 17:08] Thorsten Glaser
>
> part text/plain 869
> On Thu, 7 Feb 2019, Dmitry Bogatov wrote:
>
> > Hence, I refine my proposal -- create /var/log/dmesg as 640 in
> > initscripts, *only* if it does not already exists. Ignore
> > kernel.dmesg_restrict.
>
> +1
Here is
> Hence, I refine my proposal -- create /var/log/dmesg as 640
> in initscripts, *only* if it does not already exists. Ignore
> kernel.dmesg_restrict.
Makes sense to me.
--
Pierre Ynard
On Thu, 7 Feb 2019, Dmitry Bogatov wrote:
> Hence, I refine my proposal -- create /var/log/dmesg as 640 in
> initscripts, *only* if it does not already exists. Ignore
> kernel.dmesg_restrict.
+1
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49
[2019-02-05 17:28] Thorsten Glaser
> > 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.
>
> Yes.
>
> It’s fine to adjust permissions on first install, and 0640 roo
On Tue, 5 Feb 2019, Dmitry Bogatov wrote:
> 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.
Yes.
It’s fine to adjust permissions on first install, and 0640 root:adm
a
[2019-02-04 11:09] Javier M DAW
> Would the attached patch do the trick? (/etc/init.d/bootlogs)
Thank you very much for your patch, but it seems that issue at hand
might need addition considerations, as pointed by Pierre in next email.
> --- a2019-02-04 11:01:02.0 +0100
> +++ b
control: tags -1 +moreinfo
control: user kact...@gnu.org
control: usertags -1 objections
[2019-02-04 07:58] Pierre Ynard
> > 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, /v
Would the attached patch do the trick? (/etc/init.d/bootlogs)
--- a2019-02-04 11:01:02.0 +0100
+++ b2019-02-04 11:03:45.0 +0100
@@ -15,20 +15,62 @@
[ "$DELAYLOGIN" ] || DELAYLOGIN=yes
. /lib/init/vars.sh
+# Source options
+if [ -f /etc/default/bootlogs ]
+then
+. /et
> 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
control: tags -1 +moreinfo
control: forcemerge -1 570358
[2019-01-24 10:17] Pierre Ynard
>
> part text/plain 742
> > Interesting. On my system `/var/log/dmesg' is 640, root:adm, which is
> > quite restrictive. If I run `/etc/init.d/bootlogs' again, it stays so.
> >
> > But
> Interesting. On my system `/var/log/dmesg' is 640, root:adm, which is
> quite restrictive. If I run `/etc/init.d/bootlogs' again, it stays so.
>
> But if I remove `/var/log/dmesg' and re-run `/etc/init.d/bootlogs',
> `/var/log/dmesg' becomes 644.
>
> I believe adjustment to `/etc/init.d/bootlogs'
That file is not written by rsyslog so this bug was misfiled
> Am 09.07.2017 um 10:06 schrieb mv87 :
>
> Package: rsyslog
> Version: 8.24.0-1
> Severity: normal
> Tags: security
>
> According to https://wiki.debian.org/NewInStretch 'dmesg' should require
> superuser privileges.
> /var/log/dmesg
Package: rsyslog
Version: 8.24.0-1
Severity: normal
Tags: security
According to https://wiki.debian.org/NewInStretch 'dmesg' should require
superuser privileges.
/var/log/dmesg is world-readable which might undermine the restriction set by
kernel.dmesg_restrict = 1.
-- System Information:
Debia
13 matches
Mail list logo