[GH-ISSUE #2062] keepassxc: single-instance option does not work (private-tmp)

gitea-mirror commented

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

Owner

Originally created by @t4777sd on GitHub (Jul 24, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2062

The private-tmp feature breaks the keep in single-instance option of keepass. It writes to that directory a lock file / socket. And, since it is private, a new instance cannot read it and thus launches. It would be nice to fix the profile to not do this so features remain the same.

Until that is done is there is a way to fix this in keepassxc.local without editing the original profile?

Originally created by @t4777sd on GitHub (Jul 24, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2062 The private-tmp feature breaks the keep in single-instance option of keepass. It writes to that directory a lock file / socket. And, since it is private, a new instance cannot read it and thus launches. It would be nice to fix the profile to not do this so features remain the same. Until that is done is there is a way to fix this in keepassxc.local without editing the original profile?

gitea-mirror

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

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 08:02:35 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 24, 2018):

You can use ignore private-tmp

@SkewedZeppelin commented on GitHub (Jul 24, 2018): You can use `ignore private-tmp`

gitea-mirror commented

2026-05-05 08:02:37 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 29, 2018):

@t4777sd Does it write to specific directory within /tmp? If so, we can whitelist that specific directory instead of using private-tmp.

@chiraag-nataraj commented on GitHub (Jul 29, 2018): @t4777sd Does it write to specific directory within `/tmp`? If so, we can whitelist that specific directory instead of using `private-tmp`.

gitea-mirror commented

2026-05-05 08:02:39 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 29, 2018):

Or if we used mkfile to touch those files, could we then whitelist those specific files? It would be nice to keep the isolating properties of private-tmp.

@chiraag-nataraj commented on GitHub (Jul 29, 2018): Or if we used `mkfile` to touch those files, could we then whitelist those specific files? It would be nice to keep the isolating properties of `private-tmp`.

gitea-mirror commented

2026-05-05 08:02:41 -06:00

Author

Owner

@t4777sd commented on GitHub (Jul 29, 2018):

It writes to the following

/tmp/keepassxc-[user].lock
/tmp/keepassxc-[user].socket

Replace [user] by the current user so if that is dan it would be keepassxc-dan.lock

@t4777sd commented on GitHub (Jul 29, 2018): It writes to the following /tmp/keepassxc-[user].lock /tmp/keepassxc-[user].socket Replace [user] by the current user so if that is dan it would be keepassxc-dan.lock

gitea-mirror commented

2026-05-05 08:02:42 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 29, 2018):

Hmm, if we implement variables ${USER} and ${UID} (which was suggested on an issue somewhere...), then we could do a

mkfile /tmp/keepassxc-${USER}.lock
mkfile /tmp/keepassxc-${USER}.socket
whitelist /tmp/keepassxc-${USER}.lock
whitelist /tmp/keepassxc-${USER}.socket

or something similar (although I'm not sure how keepassxc would react if the files existed but nothing was listening...)

@chiraag-nataraj commented on GitHub (Jul 29, 2018): Hmm, if we implement variables `${USER}` and `${UID}` (which was suggested on an issue somewhere...), then we could do a ``` mkfile /tmp/keepassxc-${USER}.lock mkfile /tmp/keepassxc-${USER}.socket whitelist /tmp/keepassxc-${USER}.lock whitelist /tmp/keepassxc-${USER}.socket ``` or something similar (although I'm not sure how keepassxc would react if the files existed but nothing was listening...)

gitea-mirror commented

2026-05-05 08:02:44 -06:00

Author

Owner

@t4777sd commented on GitHub (Jul 30, 2018):

I tested it with those files pre-created and re-opened it and it caused no issues for keepass. So, I guess the only thing left is the ${USER} ability

@t4777sd commented on GitHub (Jul 30, 2018): I tested it with those files pre-created and re-opened it and it caused no issues for keepass. So, I guess the only thing left is the ${USER} ability

gitea-mirror commented

2026-05-05 08:02:47 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 30, 2018):

Cool. I think we should be able to do that.

@chiraag-nataraj commented on GitHub (Jul 30, 2018): Cool. I think we should be able to do that.

gitea-mirror commented

2026-05-05 08:02:48 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 30, 2018):

Side question: @t4777sd, did you use mkfifo for the socket? We may need to bring in an option mkfifo if keepassxc can't deal with a regular file at keepassxc-${USER}.socket (to be fair, it might be good to have anyway).

@chiraag-nataraj commented on GitHub (Jul 30, 2018): Side question: @t4777sd, did you use mkfifo for the socket? We may need to bring in an option `mkfifo` if `keepassxc` can't deal with a regular file at `keepassxc-${USER}.socket` (to be fair, it might be good to have anyway).

gitea-mirror commented

2026-05-05 08:02:48 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 30, 2018):

@netblue30 I was looking at the code, and this variable already exists internally as I understand it (cfg.username). But I'm not sure exactly where the variable substitution should take place. I assume it would be somewhere in fs_whitelist.c...?

@chiraag-nataraj commented on GitHub (Jul 30, 2018): @netblue30 I was looking at the code, and this variable already exists internally as I understand it (`cfg.username`). But I'm not sure exactly where the variable substitution should take place. I assume it would be somewhere in `fs_whitelist.c`...?

gitea-mirror commented

2026-05-05 08:02:50 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 30, 2018):

Or...in util.c?

@chiraag-nataraj commented on GitHub (Jul 30, 2018): Or...in `util.c`?

gitea-mirror commented

2026-05-05 08:02:52 -06:00

Author

Owner

@Vincent43 commented on GitHub (Aug 18, 2018):

Does KeePassXC honor TMPDIR? If yes, you may simply add env TMPDIR=/home/user/.cache to its profile. That would be much simpler than adding new code.

@Vincent43 commented on GitHub (Aug 18, 2018): Does KeePassXC honor `TMPDIR`? If yes, you may simply add `env TMPDIR=/home/user/.cache` to its profile. That would be much simpler than adding new code.

gitea-mirror commented

2026-05-05 08:02:53 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 19, 2018):

Yes, it does (just tested). I suppose that solves this issue then (maybe we should add it to the profile?).

@chiraag-nataraj commented on GitHub (Aug 19, 2018): Yes, it does (just tested). I suppose that solves this issue then (maybe we should add it to the profile?).

gitea-mirror commented

2026-05-05 08:02:55 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 19, 2018):

@t4777sd Can you verify that the new profile fixes this issue?

@chiraag-nataraj commented on GitHub (Aug 19, 2018): @t4777sd Can you verify that the new profile fixes this issue?

gitea-mirror commented

2026-05-05 08:02:56 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Aug 22, 2018):

@chiraag-nataraj I had some weird issues with f9aeac080a
does 5ee6ed83bb work for you?

@SkewedZeppelin commented on GitHub (Aug 22, 2018): @chiraag-nataraj I had some weird issues with f9aeac080a830fc1aaf07f0beff781a1ed7e42ad does 5ee6ed83bb2f631f2c04696357c0863af59e4e7b work for you?

gitea-mirror commented

2026-05-05 08:02:57 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 22, 2018):

@SkewedZeppelin Lemme try (I don't actually use keepassxc lol, but I'll try it for this 😂)

@chiraag-nataraj commented on GitHub (Aug 22, 2018): @SkewedZeppelin Lemme try (I don't actually _use_ `keepassxc` lol, but I'll try it for this :joy:)

gitea-mirror commented

2026-05-05 08:02:58 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 22, 2018):

HAHAHAHAHAHA...hahahahahaha...ha. Oh god, this is too good. I think the fix for #942 breaks your fix. The sandbox name is changed to keepassxc-1 and it doesn't join the existing one.

@chiraag-nataraj commented on GitHub (Aug 22, 2018): HAHAHAHAHAHA...hahahahahaha...ha. Oh god, this is too good. I think the fix for #942 breaks your fix. The sandbox name is changed to `keepassxc-1` and it doesn't join the existing one.

gitea-mirror commented

2026-05-05 08:03:00 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 22, 2018):

But also, join-or-start should attach to the existing one if it's specified, shouldn't it?

@chiraag-nataraj commented on GitHub (Aug 22, 2018): But also, `join-or-start` should attach to the existing one if it's specified, shouldn't it?

gitea-mirror commented

2026-05-05 08:03:02 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 22, 2018):

Or maybe it's because I have hidepid enabled...lemme see.

@chiraag-nataraj commented on GitHub (Aug 22, 2018): Or maybe it's because I have `hidepid` enabled...lemme see.

gitea-mirror commented

2026-05-05 08:03:02 -06:00

Author

Owner

@Vincent43 commented on GitHub (Aug 22, 2018):

@chiraag-nataraj yes, sorry I forgot that. We have join-or-start on several profiles so it's weird this one doesn't work.

@Vincent43 commented on GitHub (Aug 22, 2018): @chiraag-nataraj yes, sorry I forgot that. We have `join-or-start` on several profiles so it's weird this one doesn't work.

gitea-mirror commented

2026-05-05 08:03:03 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 22, 2018):

No, it's because of hidepid, since join-or-start joins by looking for the pid.

@chiraag-nataraj commented on GitHub (Aug 22, 2018): No, it's because of `hidepid`, since `join-or-start` joins by looking for the pid.

gitea-mirror commented

2026-05-05 08:03:03 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 22, 2018):

So yes, @SkewedZeppelin, this is fixed now :) @t4777sd I'm going to close this now, but feel free to re-open if the profile in master doesn't work for you.

@chiraag-nataraj commented on GitHub (Aug 22, 2018): So yes, @SkewedZeppelin, this is fixed now :) @t4777sd I'm going to close this now, but feel free to re-open if the profile in master doesn't work for you.

gitea-mirror referenced this issue

2026-05-05 10:10:43 -06:00

[PR #1390] [MERGED] Fix #1383 #3938

Rows
Columns

[GH-ISSUE #2062] keepassxc: single-instance option does not work (private-tmp) #1390