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.

A Tiny Little Error in the Post-Install, of the Debian / Stretch Package ‘xrdp’

One of the projects which I have just undertaken on the newly reactivated computer I name ‘Klexel’ was, to install an XRDP Server on it, so that I’ll be able to create remote sessions on it.

In case readers do not know, XRDP implements an analogue of the RDP protocol, but only acts as a go-between, that listens on another port, starts a VNC session, and then makes an internal connection to the VNC session, looping back to port ‘′ by default. And, if multiple clients of that sort are connected, the VNC ports continue with the numbering ‘5901…’ One big problem in trying to use VNC all by itself is, the need to have physical access to the machine, to start a new VNC session, to which multiple viewers may connect, including a person sitting in front of that machine. And another way in which XRDP can be used, is to connect to the X-Server / Xorg Session already running locally…

If the user wants to allow connecting to an existing, local X-Server session, then he needs to install the package ‘xorgxrdp’ from the repositories. What this will do is to install the X-Server modules that allow ‘connections from the side’ like that. Using this package requires a restart of the X-Server, once after installing it, while using Xrdp only for remote sessions, does not.

AFAIK, Connecting to an existing local X-Server session additionally requires that the package ‘x11vnc’ be installed, but I have not tested this.

The way I’ve chosen to use ‘xrdp’ for the moment is, with the additional package ‘tigervnc-standalone-server’, that is not automatically selected as a dependency.

I first tried to install the package ‘xrdp’ (meaning, the 32-bit version under Debian / Stretch) from the repository, only to find that there was a bug in the post-install script. It would generate an RSA Key-Pair, which is the correct thing to do, but it would then try to install that key-pair in the file:


The problem is, that this file is first set with wrong attributes. It belongs to user ‘xrdp’, to group ‘root’, and has permission-bits set, so that ‘xrdp’ can read and write, but ‘root’ cannot. This might be brilliant once the server is running, but because apt-get is only running as ‘root’, which does not yet belong to group ‘xrdp’, the post-installation hangs, not in generating the keys, but just in trying to write them to that file.

I’ve tried changing the attributes concurrently with the waiting script, as well as afterwards, re-attempting to configure the package. But the additional problem then becomes the fact that the post-install script deletes whatever file was already there, and then just recreates one with the incorrect attributes again.

I think a lot of other users would like it, if the package became installable on 32-bit systems.

What I did instead was, to custom-compile Xrdp, and to install my custom-compilation. It runs beautifully.



Update to Computer Phosphene Last Night

Yesterday evening, a major software update was received to the computer which I name ‘Phosphene’, putting its Debian version to 9.9 from 9.8. One of the main features of the update was, an update to the NVIDIA graphics drivers, as installed from the standard Debian repositories, to version 390.116.

This allows the maximum OpenGL version supported by the drivers to be 4.6.0, and for the first time, I’m noticing that my hardware now limits me to OpenGL 4.5 .

The new driver version does not come with an update to the CUDA version, the latter of which merits some comment. When users install CUDA to Debian / Stretch from the repositories, they obtain run-time version 8.0.44, even though the newly-updated drivers support CUDA all the way up to version 9. This is a shame because CUDA 8.0 cannot be linked to, when compiling code on the GCC / CPP / C++ 6 framework, that is also standard for Debian Stretch. When we want code to run on the GPGPU, we can just load the code onto the GPU using the CUDA run-time v8.0.44, and it runs fine. But if we want to compile major software against the headers, we are locked out. The current Compiler version is too high, for this older CUDA Run-Time version. (:1) (:4)

But on the other side of this irony, I just performed an extension of my own by installing ‘ArrayFire‘ v3.6.3 , coincidentally directly after this update. And my first attempt to do so involved the binary installer that ships with its own CUDA run-time libraries, those being of version 10. Guess what, Driver version 390 is still not high enough to accommodate Run-Time version 10. This resulted in a confusing error message at first, stating that the driver was not high enough, apparently to accommodate the run-time installed system-wide, which would have been bad news for me, as it would have meant a deeply misconfigured setup – and a newly-botched update. It was only after learning that the binary installer for ArrayFire ships with its own CUDA run-time, that I was relieved to know that the system-installed run-time, was fine…


(Updated 4/29/2019, 20h20 … )

Continue reading Update to Computer Phosphene Last Night