-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run AppImages with firejail if possible #32
Labels
enhancement
New feature or request
Comments
Related to #99. |
Good idea is to add support for another folder for Appimages that should be Firejailed, for example:
Thus, e.g. for an ~/Applications-jailed/jailed-app.Appimage the .desktop file should be the way appimaged does it:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Similar to appimaged, when firejail is available, AppImageLauncher should use it to run AppImages.
We need to decide whether to always use firejail or give the user control about this. I personally always prefer to give user control about such features. I could imagine to provide a checkbox in the integration dialog, and add "Enable/Disable firejail" desktop actions, depending on the current state. We could add an additional key to keep the state for this inside the desktop files, and wouldn't need to track the state outside.
Also, in case firejail is enabled, we could provide a "Run without firejail" action so that users don't have to disable and re-enable firejail in such situations. We could further provide a "Run with firejail" option when appropriate, but I don't think this would be of much use, so in case Firejail is disabled for an AppImage, I'd have the user enable support for Firejail again in order to use it.
This approach also has a UX component: The entries would have a really similar wording, making it difficult for the user to differentiate between them. As many users don't read the actual entries but recognize different entries with some, I'd say, "visual patterns" they have in mind, we could avoid any accidental mistaken runs this way.
The text was updated successfully, but these errors were encountered: