Why did dmesg become a priveleged operation suddenly?

Why is dmesg all of a sudden a priveleged operation by default?

$ dmesg
dmesg: read kernel buffer failed: Operation not permitted
$ sysctl kernel.dmesg_restrict
kernel.dmesg_restrict = 1

Sounds like a new kernel change to me. Maybe git.kernel.org has some commit for it?

I have a fairly long root password, typing it every time I want to use dmesg, which is quite often, is ridiculous.

For those interested this new default restriction can be turned off with

sudo sysctl kernel.dmesg_restrict=0

To make it permanent each boot add this setting to /etc/sysctl.d/99-sysctl.conf.

echo 'kernel.dmesg_restrict=0' | sudo tee -a /etc/sysctl.d/99-sysctl.conf



Did you find the issue in kernel 5.0 or 5.1 (which has just showed up in unstable)?

Both unstable and testing repos, VM and bare metal systems, using both 4.19 and 5.0 kernels.

Must be a new build default with the last batch of kernels, whether it is kernel dev initiated or Manjaro team config I don't know.

It was changed by the Manjaro team.

This is the example for 5.0, but you can find a similar commit for other Kernels.

1 Like

Stupid bloody nanny state decision.


I don't really get it either. It's not like you can manipulate the system via dmesg. It's just a log viewer. Right? :slight_smile:


It is for security reasons. See also here. So beside Intel we also decided to go this step.


I disagree - most users here use single-user desktops.
I mean there are many more things that Manjaro could do to improve security more than restricting kernel log to root...

On the other hand not much of an issue for experienced uses, as you can use sysctl to alter the behaviour.
But for newbies?
We now have to tell them to use sudo with dmesg in order to get info and post it on the forum (visible to everyone) - thus in some form negating the security improvement.

While we're at it:
If you already restrict dmesg access, you could also restrict access to kernel symbol addresses with kernel.kptr_restrict=1 (or even 2 to hide them completely) and setting kernel.unprivileged_bpf_disabled=1.

1 Like

SMH. Another plus for building my own kernels.

The way I look at this: if a 'bad actor' has physical access to your machine, then needing sudo for dmesg is totally worthless.


No not right, if some has physical or remote access to your machine, what should be prevented next is privilege escalation. Dmesg gives enough info away in regards to firewalls or when programs segfault or throw other error messages. journalctl is no different.


I'll concede this point IF you don't have control over who accesses your machine. I'm the only user of this machine; it's firewalled and no inbound ssh, etc.

Even my wife's windows machine...nobody just waltzes into the house, sits down and starts using it, unless I've previously made a user account for them. If I catch any of them playing 'script-kiddie', they'll be banned forever and ever, amen. Same thing goes for my wifi.

I have no experience on the "security" part of this, but whatever stops dmesg to give sensitive info away, does not stop journalctl -k.
But please, don't spread this info.. :stuck_out_tongue_winking_eye:


Even if some one was logged in as you because you walked away from the computer, it doesn't mean they have root access.

Well yeah, journalctl should be sudoers only too. :man_facepalming:

1 Like

Thanks for posting this @sueridgepipe. Just a quick question. There is 50-max_user_watches.conf only, in /etc/sysctl.d/ (on kde stable), so would adding the following, under the one line that .conf contains, work?

echo 'kernel.dmesg_restrict=0' | sudo tee -a /etc/sysctl.d/50-max_user_watches.conf

See the Arch Wiki article I linked for details on sysctl file naming and execution order.

It is convention to add user specific custom sysctl overrides to 99-sysctl.conf.

I wouldn't use 50-max_user_watches.conf as it is a Manjaro specific profile overlay file.

$ pacman -Fs 50-max_user_watches.conf
extra/manjaro-iso-profiles-official 17.1.12-1

It would still work, but better to isolate your specific sysctl overrides IMHO.

1 Like

Thanks for responding. Sorry, but I haven't really understood. I'd been able to understand that the Arch wiki said "add or modify the appropriate lines in /etc/sysctl.d/99-sysctl.conf or another applicable parameter file in /etc/sysctl.d/" and mistakenly thought whatever was in there would do. At this point, unfortunately the rest of what I'm reading is beyond me, eek.

Are you saying to enter the quoted code in the terminal? I don't know what my specific sysctl overrides are.

The sysctl command enables kernel parameters to be set dynamically, dmesg_restrict is the kernel parameter to override to enable unrestricted dmesg.

Just make sure this file exists ...

$ cat /etc/sysctl.d/99-sysctl.conf 

The command simply creates this file in one line.

Forum kindly sponsored by