[GH-ISSUE #2873] keepassxc: cannot save database file (whitelisting issue) #1796

New issue

Closed

opened 2026-05-05 08:28:15 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 08:28:15 -06:00

Owner

Originally created by @crass on GitHub (Jul 27, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2873

Here is some strace output showing KeepassXC saving an open database

lseek(22</home/crass/#8 (deleted)>, 0, SEEK_SET) = 0
fdatasync(22</home/crass/#8 (deleted)>) = 0
linkat(AT_FDCWD, "/proc/self/fd/22", AT_FDCWD, "/home/crass/test.kdbx", AT_SYMLINK_FOLLOW) = -1 EEXIST (File exists)
linkat(AT_FDCWD, "/proc/self/fd/22", AT_FDCWD, "/home/crass/test.kdbx.PBMCDC", AT_SYMLINK_FOLLOW) = 0
close(22</home/crass/#8 (deleted)>)     = 0
rename("/home/crass/test.kdbx.PBMCDC", "/home/crass/test.kdbx") = -1 EBUSY (Device or resource busy)
unlink("/home/crass/test.kdbx.PBMCDC")    = 0

So it has an open fd to the saved database, whose path has been unlinked. It tries to link the fd to the desired path, but that path already exists because that's the database without changes. Then it creates a temporary path from fd. Next it tries to rename the temporary file to the db name, but fails.

Using rename like this is a common technique here's an excerpt from the man page for rename:

If newpath already exists, it will be atomically replaced (subject to a
few conditions; see ERRORS below), so that there is no point  at  which
another process attempting to access newpath will find it missing.

I believe the reason rename is failing is ultimately because the path is a mount point (because its mount binded with whitelist) and those can't be renamed.

Ok, so I'd expect this to be a common behavior for many apps. Is there a solution for this that doesn't require modifying the app? I know that if I put the file in a directory and whitelist the directory, then everything works fine (the mount point is the dir now, instead of the file in the dir).

Is this documented somewhere? If not, where should it be? The user may not even realize that the problem is resulting because of firejail. How to make them aware as painlessly as possible?

Originally created by @crass on GitHub (Jul 27, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2873 Here is some strace output showing KeepassXC saving an open database ``` lseek(22</home/crass/#8 (deleted)>, 0, SEEK_SET) = 0 fdatasync(22</home/crass/#8 (deleted)>) = 0 linkat(AT_FDCWD, "/proc/self/fd/22", AT_FDCWD, "/home/crass/test.kdbx", AT_SYMLINK_FOLLOW) = -1 EEXIST (File exists) linkat(AT_FDCWD, "/proc/self/fd/22", AT_FDCWD, "/home/crass/test.kdbx.PBMCDC", AT_SYMLINK_FOLLOW) = 0 close(22</home/crass/#8 (deleted)>) = 0 rename("/home/crass/test.kdbx.PBMCDC", "/home/crass/test.kdbx") = -1 EBUSY (Device or resource busy) unlink("/home/crass/test.kdbx.PBMCDC") = 0 ``` So it has an open fd to the saved database, whose path has been unlinked. It tries to link the fd to the desired path, but that path already exists because that's the database without changes. Then it creates a temporary path from fd. Next it tries to rename the temporary file to the db name, but fails. Using rename like this is a common technique here's an excerpt from the man page for rename: ``` If newpath already exists, it will be atomically replaced (subject to a few conditions; see ERRORS below), so that there is no point at which another process attempting to access newpath will find it missing. ``` I believe the reason rename is failing is ultimately because the path is a mount point (because its mount binded with whitelist) and those can't be renamed. Ok, so I'd expect this to be a common behavior for many apps. Is there a solution for this that doesn't require modifying the app? I know that if I put the file in a directory and whitelist the directory, then everything works fine (the mount point is the dir now, instead of the file in the dir). Is this documented somewhere? If not, where should it be? The user may not even realize that the problem is resulting because of firejail. How to make them aware as painlessly as possible?

gitea-mirror

2026-05-05 08:28:15 -06:00

closed this issue
added the
duplicate
label

gitea-mirror commented

2026-05-05 08:28:18 -06:00

Author

Owner

@crass commented on GitHub (Jul 27, 2019):

Ok, I now see this is a well known issue as I suspected. See #2071, #1355, #1793. So closing

@crass commented on GitHub (Jul 27, 2019): Ok, I now see this is a well known issue as I suspected. See #2071, #1355, #1793. So closing

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1796

No description provided.

Rows
Columns