Is it safe to share a .kdbx file on the network?

[rdiez]

I have been reading around, and it looks like the Keeshare feature is broken and cannot really be relied upon.

The question is then, is it safe to place a .kdbx file on a network file server and share it with other users for concurrent access?

I guess that depends on how KeePassXC is written. Sharing a .kdbx file does not seem out of the question, as I have seen the following options under "Settings > General > File Management":
[x] Automatically save after every change
[x] Automatically reload the database when modified externally

Does KeePassXC attempt to lock the .kdbx file?

What happens if the underlying filesystem does not support locking? Does the user at least get a warning?

Does it lock the file the whole time? Or only when reading from or writing to it?

If it does not lock the file the whole time, when saving changes, does KeePassXC write to a temporary file first and rename the file to its final-name.kdbx afterwards? Renaming a file is the only atomic operation many filesystems support in order to guarantee a consistent write.

What happens if you change a password, and another user modifies the shared .kdbx file in the meantime? Are the other user's changes overwritten by the current user? Does the user get a warning before or afterwards?

How does KeePassXC realise that a file on a network share has changed? inotify and co. probably do not work over NFS, SSHFS or SMB/CIFS. Does it poll at regular intervals? Is there a window of opportunity for things to go awry then?

The reason I created this Issue is because I couldn't find documentation about this.

[benbrummer]

From my experience with kdbx on sharepoint and Nextcloud.
I had one or two times original.kdbx and next to it a original.kdbx.. Same with Nextcloud original.kdbx and original.kdbx-conflict.

The reason here seams to be the delay

• Local modification on client x + manual/auto save
• Sametime local modification on client y + manual/auto save
• One of them uploads first, sharepoint/nextcloud can not handle the upload/merge for the other one. KeepassXC is not involved here at all, but you need to merge the kdbx files manually afterwards. This works well with KeePassXC, not sure about other clients (IOS/Android)

So as soon as a synchronisation backend is involved, it can happen that a conflict occurs, without direct involvement of KeePassXC. The resulting conflict can and needs to be solved by a manual merge, within KeepassXC (Database => Merge from Database...).

Considerations:

• Use a fast/instant synchronisation backend

To be tested:

• Slow backend => try to increase Autosave delay for reducing the chance of concurrent uploads and therefore conflicts in the backend.
• As you already mentioned File-Management options.
• Access the files directly in the backend e.g. WebDav for Nextcloud (There is still some caching/delay involved)
• AutoOpen by users might increase the chance of concurent save operations

In total a really interesting topic.

Single user an easy option
Single user with multiple devices (KeePassXC+Nextcloud, Keepass2Android+Webdav) AutoOpen/Autosafe already caused some conflict files due to "slow" backend. With more users and devices, the chance of conflicts will increase.

Slow backend:
Modification con pc, shutdown before upload was handled by Nextcloud Client, modification on Android afterwards => conflict

To answer your question: I would consider it safe to store it on any shared location. There might be conflict files, but this can be resolved by merging the files manually through KeePassXC. Testing with the different options File-Management/Autosave/AutoOpen... might reduce the chance of conflicts.

[droidmonkey]

The question is then, is it safe to place a .kdbx file on a network file server and share it with other users for concurrent access?

YMMV, really depends on the concurrency of database writes

Does KeePassXC attempt to lock the .kdbx file?

No

What happens if the underlying filesystem does not support locking? Does the user at least get a warning?

If the file is inaccessible at time of write the user will get an error and they will have to try again.

Does it lock the file the whole time? Or only when reading from or writing to it?

File is locked by the OS when we open it for writing. However, that can get interesting depending on how you mounted the network share. This occurs only when a save has been initiated.

If it does not lock the file the whole time, when saving changes, does KeePassXC write to a temporary file first and rename the file to its final-name.kdbx afterwards? Renaming a file is the only atomic operation many filesystems support in order to guarantee a consistent write.

There are options, the default is to write to a temporary file right next to the existing one then delete existing and rename temporary. See https://keepassxc.org/docs/KeePassXC_UserGuide#_advanced_save_options

What happens if you change a password, and another user modifies the shared .kdbx file in the meantime? Are the other user's changes overwritten by the current user? Does the user get a warning before or afterwards?

First one to lock the file wins. The other person should see a request to merge the file prior to their subsequent save.

How does KeePassXC realise that a file on a network share has changed? inotify and co. probably do not work over NFS, SSHFS or SMB/CIFS. Does it poll at regular intervals? Is there a window of opportunity for things to go awry then?

We poll the file every 30 seconds, pulling the first 1 KiB of information, to detect if the file has changed. If so, we request a merge to happen. This also happens prior to saving.

[rdiez]

First of all, thanks for your answers.

"YMMV, really depends on the concurrency of database writes" is a little worrying, and "If the file is inaccessible" does not really make sense as an answer to "if filesystem does not support locking".

In any case, I am guessing that, if some sort of smart or automatic file synchronisation backend is running in the background (like OneDrive or similar cloud systems), then all bets are off. That is usually the case, no matter the application: if 2 users modify a binary file at the same time, then resolving the conflict it not straightforward.

But that is not what I had in mind. I am asking about a standard network share in a normal office environment. I gather that, if a) you leave option "Safely save database files" turned on, and b) you mount the network share with normal settings (like you usually do with SMB/CIFS or NFS), then sharing a .kdbx among several users should be safe.

There is no need for the filesystem to support any advanced features like byte-range locks inside a file, or automatic file change notifications like inotify.

The user may be prompted and may need to manually merge changes, but the .kdbx file should never get corrupted, and the user is not kept in the dark so that he could inadvertently lose a change he just did because some else just saved other changes.

Is that assumption right? Or are there any (already known) gotchas on a standard file share?

We poll the file every 30 seconds, pulling the first 1 KiB of information, to detect if the file has changed. If so, we request a merge to happen. This also happens prior to saving.

OK, let's run this scenario in detail:

• Concurrent users A and B check prior to saving that the .kdbx file has not changed.
• User A saves to a temporary file.
• At the same time, user B saves to a temporary file.

Is KeePassXC going to use a random temporary filename like myfile.kdbx.tmp896? In this case, both users A and B will rename the temporary file to replace myfile.kdbx atomically, but only one of them would win. Will KeePassXC re-open the resulting .kdbx file immediately and check whether he won?

Or is the temporary filename always same? If so, then the whole-file locking with exclusive/write access should make one of the concurrent attempts fail.

[droidmonkey]

You are asking about standard file operations and diverse range of potential scenarios. I can't possibly answer these questions with definite answers.

Bottom line, we are a personal password manager. Using our app in a highly concurrent business environment (eg, 10+ users reading/writing the same database across a network share) is not a supported scenario. If you want guarantees in that environment then you are actually looking for an enterprise managed password service, not KeePassXC.