Ubuntu 20.10 Looking At Restricting Access To Kernel Logs With dmesg

[caligula]

You're moving the goalposts. You said "There is really no reason why a normal user should be able to view the dmesg output. There aren't any user-fixable parts there for a normal user."

Trying a different USB cable or thumb drive/joystick/etc. is perfectly user-fixable for a non-administrative user.

You can still use 'lsusb' or 'udevadm' to find out if the cable is ok and the device will appear. Modern desktop environments should notify the user user in case there are hardware issues. If it's a HID device, /dev/input file will appear. The high level apps should also auto-detect hot plugged devices. Imagine using some other OS like Mac or Windows, no sane person will try to read the kernel logs when troubleshooting the issue. The high level GUI interfaces are sufficient.

[thogs19]

Couldn't there be at least a filter where only the INFO would appear when dmesg was ran by unprivileged user?
Since my desktop is very minimal I want to access dmesg everytime I plug-in a usb to assure myself what's the name of the new usb-storage device and not gonna touch the wrong one for let's say if I want to reformat the new device.

[ssokolow]

You can still use 'lsusb' or 'udevadm' to find out if the cable is ok and the device will appear. Modern desktop environments should notify the user user in case there are hardware issues. If it's a HID device, /dev/input file will appear. The high level apps should also auto-detect hot plugged devices. Imagine using some other OS like Mac or Windows, no sane person will try to read the kernel logs when troubleshooting the issue. The high level GUI interfaces are sufficient.

First, I remember some distros not installing lsusb by default, which you'd need sudo permissions to remedy, and udevadm is something I wouldn't wish on my worst enemy. (I write blog posts about how to use it when I'm trying to gather the information I need to write new udev rules because, even with Google, the interface design is such a mess... Early versions of git, eat your heart out.)

Second, tools like that won't distingush between "device is dead" (no message on insertion) and "device failed to initialize" (bad/too-long cable, usually).

Third, modern desktop environments should inform users, but most don't in my experience, and I care about end-user experience, not "Let's fix this and then pass the buck. It's the DE's fault if the user experiences a regression, not ours." They should learn from the spirit of the kernel's userspace ABI stability and not be allowed to make a change like this unless they first get compensatory patches merged into all major DEs.

Fourth, looking in /dev/input means I have to unplug the device again, then run ls -1 /dev/input > temp.txt, then plug it in and ls -1 /dev/input > temp2.txt; diff -u temp.txt temp2.txt; rm temp.txt temp2.txt. dmesg does that for me in a single command. (I don't know about your distro, but it's a crapshoot whether *buntu will put an alias in the by-id and by-path folders.)