[GH-ISSUE #2147] Allow persistent cache of appimage desktop integration prompt

gitea-mirror commented

2026-05-05 08:07:04 -06:00

Owner

Originally created by @crass on GitHub (Oct 8, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2147

When some appimage programs run (ie. firefox), a dialog prompts the user if they want to integrate with the desktop. I never do this, but I suspect it adds some desktop files. Regardless of the way you answer, a second dialog will ask if you want the answer to the first question remembered. This is implemented by storing files in the directory ${HOME}/.local/share/appimagekit. However, using the default firefox profile, this directory is not whitelisted so the preference is not persisted across jailed firefox executions.

I see 3 reasonable solutions:

Add whitelist ${HOME}/.local/share/appimagekit/Firefox_no_desktopintegration to firefox-common.profile
Add whitelist ${HOME}/.local/share/appimagekit to whitelist-common.profile
Whitelist ${HOME}/.local/share/appimagekit in an appimage specific way. For instance, (a) hardcoding profile_add("whitelist ${HOME}/.local/share/appimagekit") when --appimage is passed. Or (b) having a file whitelist-appimage.inc, which gets loaded when --appimage is specified.

My preference is for 3.b because it's more user-configurable than 3.a and is appimage specific. The (extremely minor) drawback for 3 (and 2) is that if the appimage is malicious, they will be able to see all the responses for other appimage programs. I don't see how that could really be a security issue though.

@netblue30, what are your thoughts on this? Would a 3.b be acceptable?

Originally created by @crass on GitHub (Oct 8, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2147 When some appimage programs run (ie. `firefox`), a dialog prompts the user if they want to integrate with the desktop. I never do this, but I suspect it adds some desktop files. Regardless of the way you answer, a second dialog will ask if you want the answer to the first question remembered. This is implemented by storing files in the directory `${HOME}/.local/share/appimagekit`. However, using the default `firefox` profile, this directory is not whitelisted so the preference is not persisted across jailed firefox executions. I see 3 reasonable solutions: 1. Add `whitelist ${HOME}/.local/share/appimagekit/Firefox_no_desktopintegration` to `firefox-common.profile` 2. Add `whitelist ${HOME}/.local/share/appimagekit` to `whitelist-common.profile` 3. Whitelist `${HOME}/.local/share/appimagekit` in an appimage specific way. For instance, (__a__) hardcoding `profile_add("whitelist ${HOME}/.local/share/appimagekit")` when `--appimage` is passed. Or (__b__) having a file `whitelist-appimage.inc`, which gets loaded when `--appimage` is specified. My preference is for __3.b__ because it's more user-configurable than __3.a__ and is appimage specific. The (extremely minor) drawback for __3__ (and __2__) is that if the appimage is malicious, they will be able to see all the responses for other appimage programs. I don't see how that could really be a security issue though. @netblue30, what are your thoughts on this? Would a __3.b__ be acceptable?

gitea-mirror

2026-05-05 08:07:04 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 08:07:08 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 9, 2018):

IMHO 3b adds complexity to the user interface, in this regard options 2 or 3a would be better.

@smitsohu commented on GitHub (Oct 9, 2018): IMHO 3b adds complexity to the user interface, in this regard options 2 or 3a would be better.

gitea-mirror commented

2026-05-05 08:07:09 -06:00

Author

Owner

@crass commented on GitHub (Oct 9, 2018):

How does 3b add complexity to the user interface (by which I assume you mean command line)? 3b does not propose making any changes to the command line. It would add an extra whitelist-appimage.inc to the SYSCONFDIR, but that would be automatically installed. So the user would literally do nothing different than from 3a.

The difference is that 3b allows other appimage specific profile options to be added later by the user, so its more flexible.

@crass commented on GitHub (Oct 9, 2018): How does __3b__ add complexity to the user interface (by which I assume you mean command line)? __3b__ does not propose making any changes to the command line. It would add an extra `whitelist-appimage.inc` to the `SYSCONFDIR`, but that would be automatically installed. So the user would literally do nothing different than from __3a__. The difference is that __3b__ allows other appimage specific profile options to be added later by the user, so its more flexible.

gitea-mirror commented

2026-05-05 08:07:10 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 9, 2018):

To me it seemed that you could reach your goals as well with 2 or 3a, in which case complexity in the profile infrastructure would be something to consider.

But I don't use appimages myself and indeed don't have a strong opinion. I'm quite easy to convince 😄

@smitsohu commented on GitHub (Oct 9, 2018): To me it seemed that you could reach your goals as well with 2 or 3a, in which case complexity in the profile infrastructure would be something to consider. But I don't use appimages myself and indeed don't have a strong opinion. I'm quite easy to convince :smile:

gitea-mirror commented

2026-05-05 08:07:11 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Oct 9, 2018):

2 seems like a bad idea because that directory should really only be whitelisted if the application needs it (i.e. if the user is running an appimage). 3a is bad because it hardcodes things that can't easily be changed (unlike an appimage-specific whitelist file). I would vote for 3b.

On another note, what happens when you vote to integrate the appimage and the directory it writes to isn't whitelisted? We may need to add ~/.local/share/applications to the whitelist-appimage.inc file, since I believe that is where it writes its .desktop files.

@chiraag-nataraj commented on GitHub (Oct 9, 2018): 2 seems like a bad idea because that directory should really only be whitelisted _if_ the application needs it (i.e. if the user is running an appimage). 3a is bad because it hardcodes things that can't easily be changed (unlike an appimage-specific whitelist file). I would vote for 3b. On another note, what happens when you vote to integrate the appimage and the directory it writes to isn't whitelisted? We may need to add `~/.local/share/applications` to the `whitelist-appimage.inc` file, since I believe that is where it writes its `.desktop` files.

gitea-mirror commented

2026-05-05 08:07:12 -06:00

Author

Owner

@crass commented on GitHub (Oct 9, 2018):

@chiraag-nataraj, I haven't tested, so take it with a grain of salt. However I believe the answer to your question is that the desktop files get written to somewhere in $HOME (probably ~/.local/share/applications). Btw, ~/.local/share/applications is already whitelisted and readonly in whitelist-common.inc. I don't know that the desktop integration itself is that important because the user will likely be running the program through firejail anyway, so the .desktop files won't be of much use. I don't use .desktop files, so I'm not certain of that assertion. The main point for me was to stop having to deal with 2 annoying pops every time I start the appimage.

@crass commented on GitHub (Oct 9, 2018): @chiraag-nataraj, I haven't tested, so take it with a grain of salt. However I believe the answer to your question is that the desktop files get written to somewhere in `$HOME` (probably `~/.local/share/applications`). Btw, `~/.local/share/applications` is already whitelisted and readonly in `whitelist-common.inc`. I don't know that the desktop integration itself is that important because the user will likely be running the program through firejail anyway, so the `.desktop` files won't be of much use. I don't use `.desktop` files, so I'm not certain of that assertion. The main point for me was to stop having to deal with 2 annoying pops every time I start the appimage.

gitea-mirror commented

2026-05-05 08:07:13 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Oct 9, 2018):

A more interesting extension (which might be useful to have for other reasons) is having conditional loading of includes. Something like:

if(appimage) include whitelist-appimage.inc

(the syntax is up for debate, of course). Basically, we should hopefully be able to not hardcode the loading of the file.

@chiraag-nataraj commented on GitHub (Oct 9, 2018): A more interesting extension (which might be useful to have for other reasons) is having conditional loading of includes. Something like: ``` if(appimage) include whitelist-appimage.inc ``` (the syntax is up for debate, of course). Basically, we should hopefully be able to not hardcode the loading of the file.

gitea-mirror commented

2026-05-05 08:07:14 -06:00

Author

Owner

@crass commented on GitHub (Oct 9, 2018):

I'm hesitant about making the config the profile parsing more complex because of introducing parsing bugs that could allow privilege escalation. Having said that, this doesn't seem too bad.

@crass commented on GitHub (Oct 9, 2018): I'm hesitant about making the config the profile parsing more complex because of introducing parsing bugs that could allow privilege escalation. Having said that, this doesn't seem too bad.

gitea-mirror commented

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

Author

Owner

@chiraag-nataraj commented on GitHub (Oct 9, 2018):

I'm hesitant about making the config the profile parsing more complex because of introducing parsing bugs that could allow privilege escalation.

Definitely. I just don't think having a file be auto-loaded without any way of turning it off (or changing which file is loaded) is really a great idea.

@chiraag-nataraj commented on GitHub (Oct 9, 2018): > I'm hesitant about making the config the profile parsing more complex because of introducing parsing bugs that could allow privilege escalation. Definitely. I just don't think having a file be auto-loaded without any way of turning it off (or changing which file is loaded) is really a great idea.

gitea-mirror commented

2026-05-05 08:07:17 -06:00

Author

Owner

@crass commented on GitHub (Oct 10, 2018):

@chiraag-nataraj, I had the if(conditional) syntax parsing nearly complete when it occurred to me that its kind of more complicated a syntax than it needs to be. I've settled on the extremely basic ?CONDITIONAL <profile line>. I flirted with the idea of using {CONDITIONAL} <profile line>, but that also seemed more complicated than it needed to be. I'm open to changing it to something else if we can settle on something reasonable. It does seem good enough as-is though.

@crass commented on GitHub (Oct 10, 2018): @chiraag-nataraj, I had the `if(conditional)` syntax parsing nearly complete when it occurred to me that its kind of more complicated a syntax than it needs to be. I've settled on the extremely basic `?CONDITIONAL <profile line>`. I flirted with the idea of using `{CONDITIONAL} <profile line>`, but that also seemed more complicated than it needed to be. I'm open to changing it to something else if we can settle on something reasonable. It does seem good enough as-is though.

Rows
Columns

[GH-ISSUE #2147] Allow persistent cache of appimage desktop integration prompt #1457