Le 06/10/2021 à 09:38, Stratos Zolotas a écrit :

On Wed, Oct 6, 2021 at 10:35 AM jdd@dodin.org wrote:

...

dmesg: read kernel buffer failed: Operation not permitted

Just do "sudo dmesg". The reason is to hide the kernel messages from the simple user for security reasons, I suppose. You can probably add a rule to allow your user to execute dmesg without sudo.

seems to be new, I used dmesg as user for ages. But I noticed the same feature on debian right now :-) but if every user is allowed to use sudo dmesg, where is the security? thanks jdd -- http://dodin.org

On 2021-10-06 04:00, Carlos E. R. wrote:

On 06/10/2021 09.53, jdd@dodin.org wrote:

...

but if every user is allowed to use sudo dmesg, where is the security?

Try add your user to group "root". Dmesg works here (15.2)

Well that is a pretty unrestricted security violation. Why not just log in as root to start with? It amounts to pretty much the same thing. It's a shame this isn't a pam-aware privileged application. RTFM pam.d But then again, one could question why it is in /usr/bin and not /usr/sbin And the irony is that everything there is user executable -- -rwxr-xr-x -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg

Am Mittwoch, 6. Oktober 2021, 14:13:49 CEST schrieb Carlos E. R.:

On 06/10/2021 14.04, Anton Aylward wrote:

...

On 2021-10-06 04:00, Carlos E. R. wrote:

...

On 06/10/2021 09.53, jdd@dodin.org wrote:

...

but if every user is allowed to use sudo dmesg, where is the security?

Try add your user to group "root". Dmesg works here (15.2)

Well that is a pretty unrestricted security violation. Why not just log in as root to start with? It amounts to pretty much the same thing.

Surely not.

The only thing I noticed is being able to see logs easily.

or ... you could search with google for "dmesg only as root", and one of the first results will be a tutorial about how to make it that way. In that tutorial you will find this: "How do I restrict unprivileged access to kernel syslog? Run the following sysctl command as root user: $ sudo sysctl -w kernel.dmesg_restrict=1" so to have it the other way around all you do is set that sysctl value to 0. cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

On Wed, 6 Oct 2021 14:38:47 +0200 "Carlos E. R." wrote:

On 06/10/2021 14.21, Mathias Homann wrote:

...

...

or ... you could search with google for "dmesg only as root", and one of the first results will be a tutorial about how to make it that way.

In that tutorial you will find this:

"How do I restrict unprivileged access to kernel syslog?

Run the following sysctl command as root user: $ sudo sysctl -w kernel.dmesg_restrict=1"

so to have it the other way around all you do is set that sysctl value to 0. Thanks.

cer@minas-tirith:~> sysctl kernel.dmesg_restrict kernel.dmesg_restrict = 0 cer@minas-tirith:~>

$ sysctl kernel.dmesg_restrict Absolute path to 'sysctl' is '/usr/sbin/sysctl', so running it may require superuser privileges (eg. root).

On 10/6/21 8:55 AM, jdd@dodin.org wrote:

Le 06/10/2021 à 14:21, Mathias Homann a écrit :

...

or ... you could search with google for "dmesg only as root", and one of the first results will be a tutorial about how to make it that way.

well... my question is more why a change after 20 years of user allowed to view dmesg?

It was probably always that way in SLES. Mark