Database mountpoints

[dsonck92]

Currently, it's possible to open multiple databases (for instance to separate corporate passwords or to share passwords with colleagues without giving away your own password). However, this requires one to know multiple passwords while the main idea of keepassxc is, it can store it for you. Hence my proposition: mounted databases.

Expected Behavior

• When an entry is added, it can optionally be configured to create a mountpoint of another database.
• It would take the stored password entry (and/or attachment for keyfile) to unlock the database.
• The resulting database (ideally) would show up as part of the tree structure.
  • The root node of the database has the same name as the file
  • The root is child of the node where the password entry resides
  • The icon indicates it's a sub database and whether it's read-only
• The database is referenced by metadata:
  • Relatively: company.kdbx
  • Or absolute: /home/dsonck92/company.kdbx`
  • Possibly with variables like environment variables (since the main database could be on multiple systems)
• The mountpoint database would be locked/unlocked at the same time as the main database is locked/unlocked
• The mountpoint can be writeable, which would cause the sub database to get updated, or read only

Current Behavior

Multiple databases can already be opened, but will result in tabs. You cannot hierarchically describe these additional databases. In addition, you can't currently unlock this database directly with a stored password from another database.

Possible Solution

Still keeping the decoding of databases separate but modify the view to make it look like they are underneath a node. Automatically redirecting any modification to the correct database. Directly call the decoding logic. The current interface already allows drag/drop between multiple databases. The only real change would be how global fill might work. Which should take all matching entries including mountpoints.

An intermediate solution would be to allow entries to open up another database, directly passing the passwords and/or keys required.

Context

• Can be used for embedding shared databases, but keeping it in a hierarchical view:

 +- Social
 +- Work
   +- company.kdbx
     +- Server passwords

• Can be used to keep password databases smaller but still organize them hierarchical
• Allows for difficult to crack passwords protecting the sub database and stored in the main database. Which can then be shared with others who could also use the same mechanism.

Debug Info

KeePassXC - Version 2.3.4
Revision: 6fe821c

Libraries:

• Qt 5.11.1
• libgcrypt 1.8.3

Operating system: Arch Linux
CPU architecture: x86_64
Kernel: linux 4.18.6-arch1-1-ARCH

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[droidmonkey]

This is already a feature (albeit undocumented) called AutoOpen. Further, once group sharing is merged in, that will be the preferred method of sharing entries.

See #1259 and #2109 for more info.

[dsonck92]

#2109 certainly seems to cover almost all features I seek. Also good to see it's not that far away from merging in. I'm currently experimenting with it to see if it fixes my issues.

A side note, as it's a syncing system, it will not allow splitting overly large databases to multiple independent files. (it's not an issue for me but I've seen mentions of such an issue)

#1259 is interesting, but seeing the share system, this will suffice.

[droidmonkey]

The group sync absolutely will let you split a large database into multiple smaller databases. You can create a group for each sub-database and only share that portion with others.

[dsonck92]

Hmmm, yes in a different way it will. I haven't thought about it that way.

Yes, you can split it and not importing all into one main db. But what I was hinting at was the ability to create larger opened databases without the file itself getting larger and without having multiple tabs.

But I think, once the auto-fill feature is more polished, this use case can be handled by opening multiple in tabs. Having one master which can auto-open with #1259 which references several grouping dbs that again take several sync dbs. So, in that way this usecase can be supported.

Anyways, I do accept #2109 as a slightly different solution to this idea. In fact, I kinda appreciate the fact I can now have several local databases limited to one machine, not syncing through nextcloud. And have them sync in different of these share_groups based on the use of the machine. A much improved version from the already existing automerge on change.