How to debug queries to SecretService

[CrfzdPQM6]

Hi, I use keepassxc to manage my keyring. How can I debug queries to SecretService? Some app is repeatedly trying to delete a passphrase in my keyring, and I can't quite (though I have suspicions) figure out which app it is ;)

[droidmonkey]

Use dbus-monitor https://linux.die.net/man/1/dbus-monitor

[CrfzdPQM6]

Wonderful. How do I track down which app caused the delete. I started the monitor, performed the action that yields the suspicious interaction, then came straight back to keepassxc, where I saw the key had been deleted. Problem is there are 1500 lines of output in just a second's interaction. There's just 20 lines or so that seem to touch on the unwanted deletion:
method call time=1671483368.434655 sender=:1.704 -> destination=org.freedesktop.secrets serial=9 path=/org/freedesktop/secrets/collection/KP_; interface=org.freedesktop. Secret.Item; member=Delete

How 'secret' is the information in this log? What's the next step?

[michaelk83]

You can pipe the dbus-monitor output to grep to reduce the noise. What you're looking for is the sender's bus ID in the Item.Delete() call. In this example, that's :1.704, but it may change every time you run that process. Use busctl --user (or equivalent) to check which process that bus ID belongs to.

The secrets in the DBus communication should be encrypted, but if you want to post those logs online, you may want to snip out any byte arrays, just in case.

[CrfzdPQM6]

Yes, the bus ID seems to be very short-lived for the process that is causing the delete. Plus, a lot of the entities have "(activatable)" as their ID, so perhaps it's 'hidden' by this?

[michaelk83]

"acivateable" just means that that process can be started with a DBus call to some API that that process provides. There are special configuration files that tell DBus how to do that. But that's not relevant to your issue.

If the process that's calling Delete() is short-lived, you'll need to figure out some way to translate its bus ID to the process name before it quits. Maybe some crazy bash voodoo like this:

dubs-monitor ... | grep 'Secret.Item' | grep 'Delete' | grep -oE 'sender=[.:0-9]+' | cut -d'=' -f2 | grep -f - <(busctl --user)

What this is supposed to do, is find the Item.Delete() call, extract the sender's bus ID, then search for it in the busctl output. See:
https://unix.stackexchange.com/a/85463/455274
https://unix.stackexchange.com/a/214768/455274

edit: This particular voodoo probably won't work, since busctl will get executed when you make this command, which is before the deleting process runs. So you may need your own monitoring script, or some even crazier voodoo...

[CrfzdPQM6]

Thank you very much. In the end I just ran busctl --user in a loop every 0.1 second and dbus-monitor in parallel and triggered the issue. I found I could also trigger it by using Skype, and that process hung around a lot longer so I could see it easily. I put all the detail here, but this is really strange behaviour: queries to SecretService seem to delete my passphrase for my GPG authentication key.
#8916

[michaelk83]

You can also enable the "Confirm when clients request entry deletion" setting. The confirmation dialog should show you the process information, if it's available.

[CrfzdPQM6]

This seems simplest, but I see I already have that checked, and something is certainly changing the db (leaving it in a state with a (*) after the name) without the confirmation dialog. How do I see the applications that have been granted permission perhaps by a 'remember me'-style checkbox?

[michaelk83]

AFAIK, KeePassXC doesn't (yet) remember authorizations permanently, so if you restart KeePassXC, it should ask again. If it doesn't, that might be a bug.

[droidmonkey]

Correct, we don't remember program associations after a restart of the program.

[CrfzdPQM6]

Hmmm, it hasn't asked about this action for a long time. Is there any way this could be persisted?