search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
21.47k stars 1.48k forks source link

Issues with the presented default collection #8611

Open espenfl opened 2 years ago

espenfl commented 2 years ago

Overview

I am on Arch and using for instance the supplied mutt_oauth2.py script supplied with Mutt or similar I get from time to time:

Traceback (most recent call last):
  File "/home/user/.local/bin/mutt_oauth2.py", line 110, in <module>
    collection = secretstorage.get_default_collection(conn)
  File "/usr/lib/python3.10/site-packages/secretstorage/collection.py", line 177, in get_default_collection
    return Collection(connection)
  File "/usr/lib/python3.10/site-packages/secretstorage/collection.py", line 45, in __init__
    self._collection.get_property('Label')
  File "/usr/lib/python3.10/site-packages/secretstorage/util.py", line 67, in get_property
    (signature, value), = self.send_and_get_reply(msg)
  File "/usr/lib/python3.10/site-packages/secretstorage/util.py", line 48, in send_and_get_reply
    raise DBusErrorResponse(resp_msg)
jeepney.wrappers.DBusErrorResponse: [org.freedesktop.DBus.Error.UnknownObject] ("No such object path '/org/freedesktop/secrets/aliases/default'",)

Steps to Reproduce

  1. Update Arch
  2. Open KeePassXC and unlock the secret service database
  3. Run something like (Python example): 
    import secretstorage
with closing(secretstorage.dbus_init()) as conn:                                                                                                                                                                                                                                                                               
collection = secretstorage.get_default_collection(conn)
  4. Repeat during a few days until you get the error above. I typically get it a couple of times during a working day. Similar code is running every 5 minutes or so.

Expected Behavior

Not having to restart KeePassXC.

Actual Behavior

Restarting KeePassXC fixes the issue.

Context

I noticed: https://gitlab.gnome.org/GNOME/libsecret/-/merge_requests/94/diffs?commit_id=d620c79d83acc1bae0bbd7153a691f952b74ca31 which probably fixes this specific error, but then I suspect we will just not find the entries that is searched for later and another error will appear.

A bit unsure how to proceed from here as I do not exactly how KeePassXC interacts with this. But it seems that the default collection is not returned on request or established and communicated as available to DBus on KeePassXC launch.

Please advice and thanks a lot for the hard work behind KeePassXC.

KeePassXC - 2.7.1 Revision: 5916a8f

Operating System: Linux Desktop Env: Gnome Windowing System: Wayland

michaelk83 commented 2 years ago

What is most likely happening is that the "default" alias is not being created. I think that returning "Unknown Object" makes more sense in this case than "Unknown Method", since the missing alias is an object. The fix you linked to is in libsecret, which AFAICT, Python SecretStorage doesn't use. It talks directly to DBus, so it will need to implement the same fix.

edit: Actually, that part of libsecret tries to create a "default" collection if it's missing, so it needs that fix to properly detect the condition. Python SecretStorage just errors-out if the default alias isn't there, so the specific error doesn't matter there.

On KeePassXC's side, you need to make sure that you have a group exposed to Secret Service, and that the DB that contains it is in the active tab (#8479). Then the default alias should be created.

espenfl commented 2 years ago

@michaelk83 Thanks for the quick reply.

Notice that all this works nicely after initial launch of KeePassXC. It typically happens after a while and then a restart of KeePassXC fixes it. Could of course happen on the first at some point due to statistical sampling. Settings and database setup should be fine I think. Seems to be something else. But not sure how to track this further. DBus does not give any standard error, but I have not increased the verbosity of it. What about logging in KeePassXC to get more info there?

michaelk83 commented 2 years ago

There is practically no logging in KeePassXC.

Do you have more than one DB open? If so, switching between them could drop/create/update the "default" alias. Otherwise, I don't see why it would suddenly disappear after some while. If you understand C++, the relevant code is at Service.cpp#L82 and Service.cpp#L164. But looking again at that code, even if you switch to a tab that doesn't have an exposed group, it should just keep the previous alias mapping, not delete it.

My only other guess is if some other client might be deleting the alias. @Aetf might have some other ideas.

You could try running dbus-monitor to see if anything touches the default alias path (/org/freedesktop/secrets/aliases/default) or calls the SetAlias method. But it can get pretty noisy, and it will only show the DBus ID of the callers, not their process.

You can run qdbus org.freedesktop.secrets to list the available object paths and check if the default alias is indeed missing or not.

Aetf commented 2 years ago

That's pretty much what I would suspect. Usually KeepassXC should ensure that there's always a default alias. Maybe some race conditions while switching the tab?

dbus-monitor is definitely worth a try to see if there's anything else fishy going on

hpfr commented 2 years ago

On a related note, could a preference be created to force a particular default collection? Using the focused database as the default can lead to secret-tool-based applications (which always use the default collection) writing to the wrong database if you use multiple databases to handle host-specific and cross-host secrets.

Edit: Turns out you can specify the collection; this argument isn’t documented in the man page, but it’s in secret-tool store --help. Still, I think it makes sense to have a way to make the default collection independent of the focused database.

I guess a preference to specify a specific database file path wouldn’t be effective when that database isn’t open, so you’d have to fall back to the focused database then. Or maybe it could be a preference to always use the database in the first (leftmost) tab? That seems pretty reliable.

droidmonkey commented 2 years ago

Forcing a default collection means you can NEVER use another database with secrettool unless you do your undocumented trick or constantly change your default collectionin settings. Using the left most database is even more ambiguous than the currently active database. At the end of the day, the currently active database is by far the best way to handle this situation without specifying specific database.

hpfr commented 2 years ago

I guess it wouldn’t be as much of a problem if keepassxc-browser didn’t simultaneously depend on the active database, as described in #7269. To elaborate a bit on the use case and problem:

At the moment, we’re stuck in this scenario where KeePassXC provides all the tools to be a complete secret management solution, but we can’t quite leverage simultaneously the features needed to make it happen.

Forcing a default collection means you can NEVER use another database with secret-tool unless you do your undocumented trick or constantly change your default collection in settings. Using the left most database is even more ambiguous than the currently active database. At the end of the day, the currently active database is by far the best way to handle this situation without specifying specific database.

Yeah, that’s not ideal. The problem is that many desktop applications blindly write to the default collection (it’s not like they can guess the names of users’ collections anyway, so it makes sense). Since these secrets can include app-specific tokens that are written or refreshed frequently in the background, users are forced to keep their host-specific database active all the time, which is untenable if they want to browse their actual main database. This means that even if the keepassxc-browser issue were fixed, not being able to visit the main database without worrying about writes to it by FdoSecrets clients would remain an issue.

I realize this is a complex use case and I’ve kind of backed myself into a corner with all the moving parts. I’m definitely open to ideas. Maybe there’s a better way to manage host-specific FDO secrets than a separate database. We already have hostname-based logic for auto-open, so maybe the FDO functionality could set a default collection matching the hostname, or something.

I’m optimistic we can figure something out, because the current state is agonizingly close to perfect already!

Actually, how is the default database set if the currently active database does not have groups exposed to the Freedesktop Secret Service? Maybe there’s a path forward there with the existing codebase…

michaelk83 commented 2 years ago

could a preference be created to force a particular default collection?

8479. For your use case, you'd map the default alias to the host-specific database. Then for the cross-host FDO secrets, you'll need to give the cross-host database some other alias (or just leave it with its natural collection name), and configure the relevant apps to write where you want them to (for KDE apps, see also https://github.com/frankosterfeld/qtkeychain/issues/219). Another option is have only the host-specific FDO database, and sync to the other DB or host via KeeShare.

I think it makes very little sense to have the default alias switch between different databases, since client apps expect to find their passwords where they stored them. If the alias is switched to a different database, the passwords will not be found.

hpfr commented 2 years ago

Thanks, that issue looks more relevant to what I’m discussing. I’ll follow up there.

espenfl commented 1 year ago

An update on this. I have two databases, one for secretservice and one for other things. I have AutoOpen in the other one that also unlocks the secretservice. It seems, so far that it is rather consistent the fact that I have to active the secretservice tab once and then all is good. If I do not do this (by default, the tab of the other one is activated after unlock) then I get these errors. Would it be possible to cycle all AutoOpen databases?

bdeshi commented 1 year ago

hello I think I'm facing a simliar problem. and the following workaround seemingly works for me. don't know if this would be helpful.