search

keepassxreboot / keepassxc

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

Don't auto close database unlock if underlying file is unavailable #9539

Open m-rz opened 1 year ago

m-rz commented 1 year ago

Summary

I'd like to address the issue that I'm experiencing on Windows with KeePassXC starting automatically on user login. My DB is synced via Google Drive, which is mounted at a certain path. In addition, I use the feature of automatically selecting the most recently used DB in KeePassXC. Unfortunately, both KeePassXC and Google Drive client are started at the same time and a specific race condition is what I get. As a result, the recently used DB file is not selected despite the proper configuration in KeePassXC. To my understanding, sometimes a following sequence of events occurs:

  1. Windows is started, a user logs in.
  2. KeePassXC and Google Drive are launched based on the registry entries in HKCU.
  3. KeePassXC starts before Google Drive finishes mounting the cloud storage at the target path.
  4. KeePassXC tries to open the DB file remembered from the last run.
  5. The DB file is not yet present at the given path.
  6. An error occurs, the DB is not being selected.
  7. Google Drive client finishes mounting the storage.
  8. There is a need for manually re-selecting the DB to open.

I guess, the issue may be related to all use cases with external file systems (e.g., #1834 seems similar).

Examples

Currently, I'm using a PowerShell script that delays the execution of KeePassXC on startup by 30 seconds. This ensures that, in most cases, at the time KeePassXC tries to read the DB file, it is already available. However, there are probably some better ways to address this. Therefore, I'd suggest some retry and backoff procedure when trying to select the recently used DB file in KeePassXC on its start. Let's say KeePassXC starts and tries to load the last DB file, and in case of an error, waits some time and tries again a few more times.

droidmonkey commented 1 year ago

We won't implement retry load because of this very specific edge case. If the file is not available its not available. Your solution to add a launch delay is the right solution. Doesn't Google drive cache files in the user profile though??

m-rz commented 1 year ago

If the file is not available its not available.

Well, the problem is KeePassXC seems to access the file at the time it's launched, even though the user does not try to unlock the DB yet. Undoubtedly, the obligatory requirement is that the file should be available at the time the user is actually interacting with KeePassXC. However, there's some time between starting the process and clicking the "Unlock" button when the status of this file doesn't matter that much. If it's not available for a fraction of a second within this time window, should it impede the workflow and enforce the user to select the file manually again from the list? Maybe that's the original problem that should be solved.

droidmonkey commented 1 year ago

Yes I could support NOT closing the database unlock dialog just because the file is missing.

the-moog commented 9 months ago

Similar, related issue here: With a suggested additional fix to this issue.

I have my Keepass Databases on a NAS, backed up to various places, and use both Windows and Linux clients. I can reach the databases from either OS from the public internet over a private VPN. The other day I was working on the NAS and needed a password to get a driver file from another system. Because the NAS was offline I could not access the external Internet or access the local files.

However KeepassXC was open on the all the PCs before the NAS was powered off. Though now the disk that hosts the database on the LAN was offline, and the internet (actually the local DNS) was down.

I can open the app and enter the password, but it then after asking for the Windows pin, tries to 'read' the file (though it's already in memory). Naturally that operation fails as the disk is missing, then Keepass closes. Preventing me from accessing it at all.

The issue is I needed to access it to complete the work on the NAS, doing the same on the phone would mean then getting the files off the phone onto the NAS HDD in the bootloader.... Something I can easily do via the terminal on the PC.

I do have Keepass2Android, but I also keep my ssh keys in that database, it was a complete faff to get them onto the PC with no LAN! Eventually entered it manually (which failed too many typos in a 2kB key) until realised I have the Microsoft 'MyPhone' app, so could use that to copy paste, even though it's very unreliable at it.

Compare that operation to Keepass2Android. This app saves a cached (closed/locked) version of the database each time you open it from the server. Should you find yourself disconnected from the true authoratitive database you can still get a password, and hence can get to the system that contains the password database!!

DanEble commented 1 month ago

Yes I could support NOT closing the database unlock dialog just because the file is missing.

This is the behavior I came here to request, though in my situation, the OS is macOS and the database is on a USB storage device.

If you want to take usability a step further, consider disabling the Unlock button when the program can know in advance that unlocking would fail, indicating the blocking conditions, and automatically enabling Unlock again when those conditions have cleared. (I wouldn't want the program to waste resources polling for a missing file every two seconds for a week, but if the OS provides reliable filesystem change notifications, this behavior would make sense.)