How to run my AppImages using FireJail.

First of all, I’d like to do some basic defining:

What is FireJail? It’s a type of sandboxing program, which can be run from the command-line, and which allows users to run certain programs which they do not trust, even with user-level access to their Linux computers.

What is an AppImage? It’s a special kind of file, that has execute permissions set, but that is also linked to its own, local version of many libraries, thereby circumventing compatibility issues. But, the way an AppImage is made, consists of a file-system image, that the kernel actually needs to mount, within which these libraries and executables exist, and that gets mounted read-only by default. The security of the computer really depends, on the kernel making sure, that none of the files in this virtual FS can be mounted, with their SETUID bits taking effect. (:1) (:2)

However, even under Linux, there is some risk in ‘arbitrary code’ running with the username of the person who caused this, since most of that user’s personal data is also stored under his or her username. Further, modern Linux computers sometimes ask for requests coming from user-space, resulting in actions by the O/S, and with elevated privileges.

The problem in running certain AppImage’s using FireJail is the fact that the most recent AppImage’s use ‘SquashFS’ as their (compressed) image, while older AppImage’s used an ISO container, which did not offer (much) compression. The version of FireJail that I can install under Debian 9 / Stretch is still of a variety, that can only run AppImage’s built with ISO Images, not with SquashFS. The following bulletin-board posting correctly identified the problem, at least for me:

Following what was suggested there, and wanting this to work, I next uninstalled the version of FireJail that ships with my distro, and cloned the following repository, after which I custom-compiled FireJail from there:

I got version 0.9.63 to work, apparently fully.

This latest version of FireJail does in fact run my AppImage’s just fine. Not only that, but now I can know that other, more recent AppImage’s can also be run with FireJail (on my main computer).

If people want to obtain the accompanying GUI, then the way to do that is, to custom-compile the accompanying ‘firetools’ project:

This parallels how the Debian ‘firetools’ package enhances the Debian ‘firejail’ package…





But, if people are only willing to use the version of FJ that comes with their package manager, then my AppImage’s will never run, for the reason I just explained.


When running AppImage’s using FireJail, one precedes the name of the AppImage with the ‘--appimage‘ command-line option, because they are a special case.

(Updated 8/29/2020, 13h05: )

Continue reading How to run my AppImages using FireJail.

Overheated Circuitry

One of the things which I do frequently, is ‘walk around’, or, ‘use public transit’, with my disposable earphones plugged in to my Samsung Galaxy S9 Smart-Phone, and listening to music. These earphones are clearly not the ones, which had the AKG seal of approval, and which shipped with the phone. But this week-end marks the second heat-wave this Summer, when outside daytime temperatures exceeded 31⁰C, with direct sunlight and not a cloud in the sky. And under those conditions, the battery of my phone starts to hit a temperature of 42⁰. One of the facts which I know is, that Lithium-Ion batteries like the one in my phone do not tolerate temperatures exceeding 41⁰C.

A peculiar behaviour which has set in for the second time, during this second heat-wave of the season, is that the music I was listening to would either back-space to the beginning of the song, or skip ahead one song, or just stop. So, a catastrophic sort of explanation I could think of would be, that the entire phone, with its battery, is finally just having a meltdown. But, a second possibility exists, that merely the chip in the earphone-cord could be malfunctioning. After all, the little pod in the earphone-cord has one button and a mike, and it’s actually cheaper to mass-produce the chip that makes it work, than it would be to mass-produce other sorts of discrete components. One cheap chip could just be malfunctioning in the extreme heat, and not the entire, complex circuitry of the phone. (:1)

The earphones cost me about $15, while the phone is much more expensive than that.

But even if it was true, that only the little remote-control in the earphone-cord was malfunctioning, this can lead to impractical situations, because just random patterns, of unreal button-press-combinations, could also send the software of my phone into a confused state, and even so, if the circuitry in the smart-phone never malfunctioned. This behaviour could get misinterpreted by the security apps of the phone, let’s say, as though somebody had ripped the earphone-cord off my head, and thrown all my possessions around.

All that was really happening was that my music was no longer playing, as I was walking home normally, in the heat, with my overheated electronics. And when I got home, my actual phone never displayed any signs of having malfunctioned.

(Updated 8/17/2019, 17h50 … )

Continue reading Overheated Circuitry

Buffer Overruns In Perspective

One problem which old code used to suffer from, was that it would causally cause slight buffer overruns, which the users never noticed, and in spite of which, the code seemed to work.

But one fact which the programming community has become aware of acutely in recent years, is that in many cases, carefully-crafted, malformed files could be given to those programs as input, in such a way that the attacker – the person who originated the malformed files – could get code to execute on the target’s computer, without this target ever being aware of the fact. Mind you, this probably did not happen in most cases. But under controlled conditions, this has often been proved possible to achieve.

So what has happened in the Linux world, is that the core libraries, against which all Linux software is compiled and linked, have been rewritten, so that they will stop a program cold, if that program causes the slightest buffer overrun. This has even been implemented in ways, that sometimes reduce performance, due to error-checking which wasn’t there before, and which is also not due to source-code belonging to any one application.

And so one result has been, that certain Linux programs no longer run, even though not one line of their source-code was ever changed. I recently had an experience which I believe to be of such a nature.

The reason these programs may no longer run, is that they were causing buffer overruns from the very beginning, only instances, which were not detected before.