Firejail: KeePassXC profile breaks features - would be fixed by $USER variable

[t4777sd]

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?

[SkewedZeppelin]

You can use ignore private-tmp

[chiraag-nataraj]

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

[chiraag-nataraj]

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.

[t4777sd]

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

[chiraag-nataraj]

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...)

[t4777sd]

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

[chiraag-nataraj]

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

[chiraag-nataraj]

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]

@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]

Or...in util.c?

[Vincent43]

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.

[chiraag-nataraj]

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

[chiraag-nataraj]

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

[SkewedZeppelin]

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

[chiraag-nataraj]

@SkewedZeppelin Lemme try (I don't actually _use_ keepassxc lol, but I'll try it for this :joy:)

[chiraag-nataraj]

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]

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

[chiraag-nataraj]

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

[Vincent43]

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

[chiraag-nataraj]

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

[chiraag-nataraj]

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.