[opensuse-factory] no permissions to see dmesg
Hi all. A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg). My Tumbleweed is up to date. What do I need to change to get the permissions back? Cheers, Michael The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt. english would be something like: reading of kernel buffer failed: operation not permitted -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I can confirm that I have the same behavior since some days. Stratos. On Mon, Nov 18, 2019 at 6:56 PM Takashi Iwai <tiwai@suse.de> wrote:
On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.
thanks,
Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/18/19 10:56 AM, Takashi Iwai wrote:
On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.
The problem definitely is with the openSUSE kernel. I get correct dmesg operation with my home-built mainline tip kernel (5.4.0-rc7), but 5.3.9-1-default from openSUSE fails. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
What's wrong exactly with dmesg requiring sudo ? Even if this wasn't the previous behavior ? On 11/18/19 5:56 PM, Takashi Iwai wrote:
On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 19.11.19 um 09:13 schrieb Martin Wilck:
On Mon, 2019-11-18 at 18:13 +0100, Michael Pujos wrote:
What's wrong exactly with dmesg requiring sudo ? Even if this wasn't the previous behavior ?
And what's wrong with using "journalctl -k -b"?
First, it does not work. seife@vbox-seife:/local> journalctl -k -b Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice. -- Logs begin at Wed 2019-09-18 14:47:35 CEST, end at Mon 2019-11-18 15:38:08 CET. -- -- No entries -- Second, performance. Try this on a 500-days-uptime machine running on slow rotating rust.
Martin
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩrg==--
Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2019-11-19 at 10:01 +0100, Stefan Seyfried wrote:
And what's wrong with using "journalctl -k -b"?
First, it does not work.
seife@vbox-seife:/local> journalctl -k -b Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice.
Well, it tells you what to do to make it work, does it not?
Second, performance.
Try this on a 500-days-uptime machine running on slow rotating rust.
You should update more often :-) Joke aside, I haven't tried. I'm curious, how long does it take? Anyway, would "dmesg" actually be useful on such a machine? The kernel log buffer might have wrapped and lost messages after such a long uptime. More often than not, you're only interested in the latest messages, for which you can use something like "journalctl --since -10m -k", which is much quicker than "journalctl -b -k". It takes a bit of changing habits, but I've come to like the journalctl command a lot. Martin N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/2019 11.26, Martin Wilck wrote:
On Tue, 2019-11-19 at 10:01 +0100, Stefan Seyfried wrote:
And what's wrong with using "journalctl -k -b"?
First, it does not work.
seife@vbox-seife:/local> journalctl -k -b Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice.
Well, it tells you what to do to make it work, does it not?
Second, performance.
Try this on a 500-days-uptime machine running on slow rotating rust.
You should update more often :-) Joke aside, I haven't tried. I'm curious, how long does it take?
Up to half an hour with just a month of logs, last time I tried on rotating rust.
Anyway, would "dmesg" actually be useful on such a machine? The kernel log buffer might have wrapped and lost messages after such a long uptime. More often than not, you're only interested in the latest messages, for which you can use something like "journalctl --since -10m -k", which is much quicker than "journalctl -b -k".
It takes a bit of changing habits, but I've come to like the journalctl command a lot.
I'll have to remember that one. I just tried, but the journal doesn't have all the text. journal
Nov 19 12:51:55 Telcontar kernel: snd_hda_intel 0000:03:00.0: CORB reset timeout#1, CORBRP = 0 Nov 19 12:51:55 Telcontar kernel: pciehp 0000:00:1c.3:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) Nov 19 12:51:55 Telcontar kernel: pciehp 0000:00:1c.2:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) Nov 19 12:51:55 Telcontar kernel: pciehp 0000:00:1c.4:pcie004: Timeout on hotplug command 0x0018 (issued 1912 msec ago) Nov 19 12:51:55 Telcontar kernel: serial 00:02: activated Nov 19 12:51:55 Telcontar kernel: r8169 0000:07:00.0 eth1: link down Nov 19 12:51:55 Telcontar kernel: r8169 0000:06:00.0 eth0: link down Nov 19 12:51:55 Telcontar kernel: ata6: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: ata8: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: ata7: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: ata5: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: r8169 0000:06:00.0 eth0: link up Nov 19 12:51:55 Telcontar kernel: PM: restore of devices complete after 4106.678 msecs Nov 19 12:51:55 Telcontar kernel: PM: Trampoline freed Nov 19 12:51:55 Telcontar kernel: OOM killer enabled. Nov 19 12:51:55 Telcontar kernel: Restarting tasks ... done.
dmesg:
[50647.969674] snd_hda_intel 0000:03:00.0: CORB reset timeout#1, CORBRP = 0 [50647.973469] pciehp 0000:00:1c.3:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) [50647.973471] pciehp 0000:00:1c.2:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) [50647.981468] pciehp 0000:00:1c.4:pcie004: Timeout on hotplug command 0x0018 (issued 1912 msec ago) [50647.985588] serial 00:02: activated [50648.001725] r8169 0000:07:00.0 eth1: link down [50648.025736] r8169 0000:06:00.0 eth0: link down [50648.295594] ata6: SATA link down (SStatus 0 SControl 300) [50648.295597] ata8: SATA link down (SStatus 0 SControl 300) [50648.295641] ata7: SATA link down (SStatus 0 SControl 300) [50648.295648] ata5: SATA link down (SStatus 0 SControl 300) [50650.182723] r8169 0000:06:00.0 eth0: link up [50650.301711] PM: restore of devices complete after 4106.678 msecs [50650.302013] PM: Image restored successfully. ********** [50650.302015] PM: Trampoline freed [50650.302042] PM: Basic memory bitmaps freed ********** [50650.302043] OOM killer enabled. [50650.302044] Restarting tasks ... done.
The "**********" mark missing lines on the journal. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXdPo1gAKCRC1MxgcbY1H 1ZWCAJ0dY3xLFONA1ao1Th9u/epUFJjgKQCdGaThOuBuebiPMVaVgTHX3A+FJWw= =YFl1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 19.11.19 um 11:26 schrieb Martin Wilck:
On Tue, 2019-11-19 at 10:01 +0100, Stefan Seyfried wrote:
And what's wrong with using "journalctl -k -b"?
First, it does not work.
seife@vbox-seife:/local> journalctl -k -b Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice.
Well, it tells you what to do to make it work, does it not?
I think "access to all logs" is a much bigger security concern than "access to dmesg".
Second, performance.
Try this on a 500-days-uptime machine running on slow rotating rust.
You should update more often :-) Joke aside, I haven't tried. I'm curious, how long does it take?
Long. Very long, at least the first try until the files are in VFS cache. Journal is ridiculously slow on rotating rust. It's even slow on ramdisk. Something like 30seconds for a "systemctl status fooo", only for retrieving the last logs from journal is not uncommon.
Anyway, would "dmesg" actually be useful on such a machine? The kernel log buffer might have wrapped and lost messages after such a long uptime. More often than not, you're only interested in the latest messages, for which you can use something like "journalctl --since -10m -k", which is much quicker than "journalctl -b -k".
Still "dmesg |tail" is orders of magnitude faster.
It takes a bit of changing habits, but I've come to like the journalctl command a lot.
I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).
Martin
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩrg== -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:
I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).
Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request? Martin N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Tue, Nov 19, 2019 at 03:25:19PM +0000, Martin Wilck wrote:
On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:
I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).
Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request?
State of the art fix is 'zypper in rsyslog'. Then you can use cp which has performance orders of magnitude better than journalctl. I don't think fixing systemd journal design is something somebody would seriously consider by now. It is not like nobody has tried, is it? Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2019-11-19 at 17:32 +0100, Michal Suchánek wrote:
On Tue, Nov 19, 2019 at 03:25:19PM +0000, Martin Wilck wrote:
On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:
I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).
Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request?
State of the art fix is 'zypper in rsyslog'. Then you can use cp which has performance orders of magnitude better than journalctl.
I don't think fixing systemd journal design is something somebody would seriously consider by now. It is not like nobody has tried, is it?
I haven't followed the development close enough to tell. But it's such a central element of modern Linux distros that it's a real shame it performs so badly. Martin
On Tue, Nov 19, 2019 at 04:57:46PM +0000, Martin Wilck wrote:
On Tue, 2019-11-19 at 17:32 +0100, Michal Suchánek wrote:
On Tue, Nov 19, 2019 at 03:25:19PM +0000, Martin Wilck wrote:
On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:
I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).
Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request?
State of the art fix is 'zypper in rsyslog'. Then you can use cp which has performance orders of magnitude better than journalctl.
I don't think fixing systemd journal design is something somebody would seriously consider by now. It is not like nobody has tried, is it?
I haven't followed the development close enough to tell. But it's such a central element of modern Linux distros that it's a real shame it performs so badly.
I would say it is not dissimilar to what we have with Spectre. If you want decent performance you need a CPU that has this issue, and if you care you apply a workaround. If you want modern system with all desktop services you need systemd that has this issue, and if you care you apply workaround. In either case persuading upstream to fix the issue was unsuccessful so far. Unlike with journal there is at least some progress with Spectre. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/2019 16.25, Martin Wilck wrote:
On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:
I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).
Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request?
That journalctl is absurdly slow in rotating disk has been known for years. I remember mail threads discussing it long ago. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXdQkYgAKCRC1MxgcbY1H 1RdKAJ9ltHoakLhcwaZm8Mm37dmLBe5NVwCfSvfzl6ROK10XuXaarguNY506UlM= =Eedj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 19.11.19 um 16:25 schrieb Martin Wilck:
Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request?
We had high level support tickets open for this for SLES12/SOC6/SOC7. It's just that the journal is designed essentially as a write only database. This is why it performs bad, even if no disk IO is involved at all. (This all was on machines with more RAM than my average machine at home has disk storage and more CPU cores than all the CPUs in my home combined, including the embedded CPUs..., so it is probably also not possible to solve the issue by "just" throwing more RAM or a bigger CPU at it. I'm quite sure there were no significantly bigger CPUs available at the time). Journal is designed to work somehow on the average developers notebook (fast SSD, reasonable amount of RAM, reboots often). It is near unusable for serious machines with big workloads. rsyslog performs fine, though. Feel free to rewrite the journal from scratch, considering serious use cases and not just toy usage. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 18. November 2019, 17:56:26 CET schrieb Takashi Iwai:
On Mon, 18 Nov 2019 17:51:47 +0100,
Michael Born wrote:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.
thanks,
Takashi
fwiw I think it's actually reasonable to restrict kernel buffer access to privileged users in openSUSE too.
On Mon, 18 Nov 2019 17:56:26 +0100 Takashi Iwai wrote:
english would be something like: reading of kernel buffer failed: operation not permitted
Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.
I observed this on tumbleweed already for some weeks. I chose to put kernel.dmesg_restrict = 0 into sysctl.conf as workaround as I thought it was a deliberate choice to restrict access. Regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I filed bug 1157066. https://bugzilla.opensuse.org/show_bug.cgi?id=1157066 Cheers, Michael Am 18.11.19 um 17:56 schrieb Takashi Iwai:
On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
W dniu 18.11.2019 o 17:51, Michael Born pisze:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Is it bad? "In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access" https://www.phoronix.com/scan.php?page=news_item&px=Dmesg-Unrestricted-2019-So-Far
On Mon, 18 Nov 2019 20:05:58 +0100, Adam Mizerski wrote:
W dniu 18.11.2019 o 17:51, Michael Born pisze:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Is it bad?
"In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access" https://www.phoronix.com/scan.php?page=news_item&px=Dmesg-Unrestricted-2019-So-Far
Basically such a change shouldn't have been done without announcement or proper discussion even if it's an intended change. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Takashi Iwai <tiwai@suse.de> [11-18-19 14:17]:
On Mon, 18 Nov 2019 20:05:58 +0100, Adam Mizerski wrote:
W dniu 18.11.2019 o 17:51, Michael Born pisze:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
Is it bad?
"In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access" https://www.phoronix.com/scan.php?page=news_item&px=Dmesg-Unrestricted-2019-So-Far
Basically such a change shouldn't have been done without announcement or proper discussion even if it's an intended change.
ah, kind of line removing the groups tags. o-o-o, maybe I should not have mentioned that :( -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Отправлено с iPhone
18 нояб. 2019 г., в 20:11, Takashi Iwai <tiwai@suse.de> написал(а):
Is it bad?
"In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access" https://www.phoronix.com/scan.php?page=news_item&px=Dmesg-Unrestricted-2019-So-Far
Basically such a change shouldn't have been done without announcement or proper discussion even if it's an intended change.
But the change is already there, so what is the point of bug report *now*? To revert, announce and then revert revert? I’d say, it becomes documentation bug - it should be mentioned in release notes.-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/11/2019 17.51, Michael Born wrote: ...
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
I suggest you create this script: Telcontar:~ # cat /usr/local/bin/englisch #!/bin/sh LANG=en_US.UTF-8 \ LC_ALL=en_US.UTF-8 \ DICTIONARY=english \ KDE_LANG=en_US.UTF-8 \ exec "$@" Telcontar:~ # Then you run: englisch dmesg and you should obtain the error message in English. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Thank you. That is useful. Michael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 18/11/19 13:51, Michael Born ha scritto:
Hi all.
A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).
My Tumbleweed is up to date. What do I need to change to get the permissions back?
Cheers, Michael
The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.
english would be something like: reading of kernel buffer failed: operation not permitted
+1: you have to siply issue "sudo dmesg" and mesages will be displayed, but I confirm that before it was possible to run dmesg as normal user. -- Marco Calistri Build: openSUSE Tumbleweed 20191112 Kernel: 5.3.9-1-default - Cinnamon 3.8.9 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (16)
-
Adam Mizerski -
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
dieter -
Larry Finger -
Marco Calistri -
Martin Wilck -
Maximilian Trummer -
Michael Born -
Michael Pujos -
Michal Suchánek -
Patrick Shanahan -
Stefan Seyfried -
Stratos Zolotas -
Takashi Iwai