tdepowersave spamming auth.log every two seconds #44

Basic information

TDE version: 14.0.9
Distribution: Debian 10 Buster (w/ standard 4.19.0-13 kernel)
Hardware: Intel i7 (arch is amd64 w/ multiarch and some non-TDE i386)

Description

My auth.log backups go as far back as Jan 3rd and it's in all of them. I'm guessing it might be related to the fix for tdepowersave to notice when AC power status changed.

Steps to reproduce

Install tdepowersave-trinity
Look at auth.log - approx 111MB per week of this:

Feb 1 17:30:23 delta dbus-daemon[9673]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.27" (uid=1000 pid=10665 comm="tdepowersave [tdeinit] ") interface="org.trinitydesktop.hardwarecontrol.InputEvents" member="GetActiveSwitches" error name="(unset)" requested_reply="0" destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=10413 comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")
Feb 1 17:30:25 delta dbus-daemon[9673]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.27" (uid=1000 pid=10665 comm="tdepowersave [tdeinit] ") interface="org.trinitydesktop.hardwarecontrol.InputEvents" member="GetActiveSwitches" error name="(unset)" requested_reply="0" destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=10413 comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")

Screenshots

The GetActiveSwitches call is related to determining the state of the lid – whether it is closed or open. And the message [system] Rejected send message means some problem at the dbus permission level.

Is it possible that the wonderful systemd was updated there and the user was not logged out / logged in? Can you try a dbus call using cli or d-feet?

I saw a similar thing when I was playing with dbus and testing a lot, even using multiple sessions. You should try a reboot and see if the problem still persists. If not, it is probably something like Slavek pointed out (like systemd update or so). But it could also be a problem with dbus service permissions, so testing on a fresh reboot is recommended.

No systemd here other than libsystemd0.

No software updates since last reboot 47 hours ago.

Dbus is present but if you want me to try a manual dbus call you'll have to give me something to copy/paste into my command line as I have no experience with that.

FWIW this doesn't appear on an old i386 Pentium II laptop but that has substantially less software installed and much older hardware although it does have tdepowersave-trinity.

ok, thanks for the info Mike. Although you don't have systemd installed, can you first have a look at the suggestion mentioend here?

If you still have isues after that, we will need to do further investigation and we will come up with some CLI command for you to test

First, to anyone following along at home, I would say don't try restarting dbus. Just reboot. Believe me, you'll thank me.

Second, no change with group="users". However Debian by default creates a separate group for each user to avoid some security problems.

I'm going to try group="audio". The audio group is allowed to play sounds and I believe it is Debian standard. However users are not added to it by default so it is not a general purpose solution. However here I add people who are allowed to login to TDE to the audio group so it might work if dbus considers secondary groups as well as primaries.

First, to anyone following along at home, I would say don't try restarting dbus. Just reboot. Believe me, you'll thank me.

👍 💯

I'm going to try group="audio". The audio group is allowed to play sounds and I believe it is Debian standard. However users are not added to it by default so it is not a general purpose solution. However here I add people who are allowed to login to TDE to the audio group so it might work if dbus considers secondary groups as well as primaries.

Ok, let us know how it goes and we take it from there.

I tried group="audio" and also group="<my user's private group>".

In both cases my screen brightness failed to set and I can't work with one screen glaring so bright I need sunglasses.

Sorry but it's late and I'm up against a hard deadline so I need to get back to work now.

Thanks for trying.

OK, seems to work fine now with group="audio".

What was happening was that tdepowersave was overriding the monitor brightness which had previously been set in .xsessionrc but once I made the two match it's OK and the auth.log spam has stopped.

Not sure if this is the ideal solution as not everyone uses group="audio". Debian and its derivatives don't use the "users" group for normal users so that doesn't work either.

Are there security reasons for not enabling these messages in context="default"?

OK, seems to work fine now with group="audio".

What was happening was that tdepowersave was overriding the monitor brightness which had previously been set in .xsessionrc but once I made the two match it's OK and the auth.log spam has stopped.

Not sure if this is the ideal solution as not everyone uses group="audio". Debian and its derivatives don't use the "users" group for normal users so that doesn't work either.

Are there security reasons for not enabling these messages in context="default"?

We assumed that the plugdev group can be useful, so plugdev is used in the default configuration file. Are your local users a member of this group?

It is a good idea that reading these switches could be allowed for everyone – in the default context. It probably can't cause sensitive information to leak there, and at the same time it doesn't allow anyone to set anything – just read.

Across all the machines I manage only four have users in plugdev. Three of those users are me and one is nagios.

I have no idea what caused any of them to be added to plugdev as we set up machines in a fairly controlled fashion. Possibly at some point in time a debian package script was adding users to plugdev. I'm going to remove them as they shouldn't be there.

I'm not a great fan of allowing unsophisticated users to plug in a memory stick their buddy gave them and thereby infecting a network but I can see that plugdev might make sense as a default for TDE for this policy.

I'm not a great fan of allowing unsophisticated users to plug in a memory stick their buddy gave them and thereby infecting a network but I can see that plugdev might make sense as a default for TDE for this policy.

Anyway, I like your idea to allow reading input switches and their states for everyone. I am convinced that we can go this way.

yes, it sounds a sensible option and safer than using plugdev.

@mgb just wondering, since you are on debian 10, did you replace systemd with sysv? any unexpected issues?

The only issue I've had with sysv in Debian is one systemd zealot DD using his packaging scripts to forcibly remove some files from /etc/init.d and me having to restore them from pre-upgrade backups. They work just fine of course.

I've used Devuan and wish I still could but Devuan's boss's response to the 2019 April Fool's incident was to laugh it off rather than investigating to see if security had actually been compromised in any way.

https://lwn.net/ml/devuan-devel/201904011105.11988.mgb-devuan@yosemite.net/

Thanks Mike. And interesting reading about Devuan April's fool, I didn't know about it.

Resolved in TDE/tdelibs#125.

FYI, the modification only affects the configuration file for dbus and has no further sequence. Thanks to this, it can also be used for the current final release without the need to update to PSB.