[GH-ISSUE #560] Missing environment variables in AppImage support #394

Closed
opened 2026-05-05 05:46:42 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @probonopd on GitHub (Jun 10, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/560

@netblue30

Just discovered that you added AppImage support to firejail. Very useful, great work!

The software inside AppImages might may the following environment variables to be set:

  • $APPIMAGE should contain the full path of the AppImage that has been mounted
  • $APPDIR should contain the full path to the mountpoint where the AppImage that has been mounted

Also, running an AppImage normally extracts its icon so that the thumbnailer in the system can use it; although I am not sure if this exceeds the scope of firejail.

Questions

  • Is it required to write a separate profile for each AppImage in order for firejail to add security over normal AppImage execution without a sandbox?
  • One of the main use cases would be for sandboxed AppImages to not inadvertently access/delete content in $HOME while still being able to use $HOME if explicitely allowed by the user. Do you have an idea/suggestion on how to achieve this? E.g., have a GUI dialog box to ask the user for permission?
Originally created by @probonopd on GitHub (Jun 10, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/560 @netblue30 Just discovered that you added AppImage support to firejail. Very useful, great work! The software inside AppImages might may the following [environment variables to be set:](https://github.com/probonopd/AppImageKit/blob/34defc0d9fc0b79735b3cdf84cd5c4d3234f9639/runtime.c#L360-L361) - `$APPIMAGE` should contain the full path of the AppImage that has been mounted - `$APPDIR` should contain the full path to the mountpoint where the AppImage that has been mounted Also, running an AppImage [normally extracts its icon](https://github.com/probonopd/AppImageKit/blob/34defc0d9fc0b79735b3cdf84cd5c4d3234f9639/runtime.c#L286-L357) so that the thumbnailer in the system can use it; although I am not sure if this exceeds the scope of firejail. Questions - Is it required to write a separate profile for each AppImage in order for firejail to add security over normal AppImage execution without a sandbox? - One of the main use cases would be for sandboxed AppImages to not inadvertently access/delete content in `$HOME` while still being able to use `$HOME` if explicitely allowed by the user. Do you have an idea/suggestion on how to achieve this? E.g., have a GUI dialog box to ask the user for permission?
gitea-mirror 2026-05-05 05:46:42 -06:00
Author
Owner

@netblue30 commented on GitHub (Jun 11, 2016):

The main AppImage functionality is there, but there are some problems. I also have to look into the icon extraction and allow it. In this moment I re-mount /usr read-only. Where does the icon go?

Is it required to write a separate profile for each AppImage

No, if a profile is not specified firejail will use /etc/firejail/default.profile. It is a very restrictive profile, it blocks access to directories such as /var/log, /sbin, /usr/sbin, and mounts read-only most of the filesystem. In the home directory it blocks ~/.ssh, ~/.mozilla, some of ~/.config, password files and encryption keys, etc.

sandboxed AppImages to not inadvertently access/delete content in $HOME

You would have to run it with --private:

$ firejail --private appimage

The home directory will be empty.

<!-- gh-comment-id:225360487 --> @netblue30 commented on GitHub (Jun 11, 2016): The main AppImage functionality is there, but there are some problems. I also have to look into the icon extraction and allow it. In this moment I re-mount /usr read-only. Where does the icon go? > Is it required to write a separate profile for each AppImage No, if a profile is not specified firejail will use /etc/firejail/default.profile. It is a very restrictive profile, it blocks access to directories such as /var/log, /sbin, /usr/sbin, and mounts read-only most of the filesystem. In the home directory it blocks ~/.ssh, ~/.mozilla, some of ~/.config, password files and encryption keys, etc. > sandboxed AppImages to not inadvertently access/delete content in $HOME You would have to run it with --private: ``` $ firejail --private appimage ``` The home directory will be empty.
Author
Owner

@probonopd commented on GitHub (Jun 11, 2016):

I also have to look into the icon extraction and allow it.

If I understand it correctly, you are not executing the AppImage and hence not running its runtime.c at all, but instead mount the AppImage using your own code and run the contained AppRun. This is perfectly fine, but in order to replicate the full AppImage functionality, you would have to replicate/copy what runtime.c does (including the icon stuff).

The icon goes to $XDG_CACHE_HOME/thumbnails/normal/.

<!-- gh-comment-id:225361696 --> @probonopd commented on GitHub (Jun 11, 2016): > I also have to look into the icon extraction and allow it. If I understand it correctly, you are not executing the AppImage and hence not running its [runtime.c](https://github.com/probonopd/AppImageKit/blob/master/runtime.c) at all, but instead mount the AppImage using your own code and run the contained AppRun. This is perfectly fine, but in order to replicate the full AppImage functionality, you would have to replicate/copy what runtime.c does (including the icon stuff). The icon goes to `$XDG_CACHE_HOME/thumbnails/normal/`.
Author
Owner

@probonopd commented on GitHub (Jun 11, 2016):

You would have to run it with --private

Imagine an app which is used to edit documents. Wouldn't that mean that all files I have saved using the application are lost when the app is closed?

<!-- gh-comment-id:225361734 --> @probonopd commented on GitHub (Jun 11, 2016): > You would have to run it with --private Imagine an app which is used to edit documents. Wouldn't that mean that all files I have saved using the application are lost when the app is closed?
Author
Owner

@netblue30 commented on GitHub (Jun 11, 2016):

Yes, they are on a tempfs filesystem.

--private is used mainly for browsers when you don't trust the addons you have installed and want to start with a clean browser to connect to a bank website. I also see --private used for running servers or daemons that don't need any info in /home.

<!-- gh-comment-id:225364210 --> @netblue30 commented on GitHub (Jun 11, 2016): Yes, they are on a tempfs filesystem. --private is used mainly for browsers when you don't trust the addons you have installed and want to start with a clean browser to connect to a bank website. I also see --private used for running servers or daemons that don't need any info in /home.
Sign in to join this conversation.
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#394
No description provided.