Feature request: Allow telling --appimage-mount to use a specific directory

Developers
1

Setting $TMPDIR allows for setting where the mounting directory will be created, but there is no option the name the mount directory itself.

An example of how this would work:
example.AppImage --appimage-mount $TMPDIR/.specific_dir

Giving no additional arguments to ‘–appimage-mount’ would simply default to how it currently works with random characters.

Implementing this would lead to more convenience to the user and allow scripts to mount to specified places instead of needing to use globs to find the AppImage’s files.

2

Please elaborate why you’d want this.

The AppImage runtime intentionally uses an ever-changing random location to ensure that no other parts of the system depend on a hardcoded mount point. This is to ensure that the contents of the AppImages are fully relocatable in the filesystem and no hardcoded paths creep in.

3

One specific scenario I can think of was creating a script to run AppImages through BubbleWrap. With no option to change the mountpoint, the only other option is to change the TMPDIR then glob it out.

I could be missing something, but I don’t understand how it would allow devs to lazily create hardcoded paths inside AppImages, because this feature would need to be activated with either an environment variable or a command line flag, both of which the user fully controls.

4

Can you elaborate a bit? I’d be interested to learn more about it.
Firejail (another sandbox) gets around this by mounting the filesystem image of the AppImage itself, at a location Firejail decides, instead of letting the AppImage do it.

5

I’ve put the script on the back burner in favor of another project I’ve been working on: GitHub - mgord9518/aisap: Golang library to make sandboxing AppImages easy

It uses a very basic profile system, trying to emulate Android-style permissions, which I think is much easier than manually configuring individual files

It currently is a bit buggy and requires squashfuse-bin to be installed on the host machine, but it has been working pretty decently for the AppImages I use daily.

2 Likes
6

GitHub - mgord9518/aisap: Golang library to make sandboxing AppImages easy seems to be a very interesting approach, actually roughly what I had in mind for go-appimage/src/appimaged at master · probonopd/go-appimage · GitHub (Golang!) but never came around to writing.

Let me know once you have something ready for testing.

7

Sounds good! I’ve just been re-working the API to be more logical and trying to implement the AppImage struct of go-appimage so they can be used interchangeably.

Unfortunately it’ll probably be a while until I can make bindings for squashfuse, but once I finish with the API it should be ready for testing (given that any program that wants to use it is okay with being packed with a squashfuse binary for the time being)

8

It’s ready for alpha testing, more information on it is available on the Reddit post I made here

9

Thank you @mgord9518 this looks very interesting.

As for myself, I don’t run apps the authors of which I don’t trust, so personally I don’t have a big need for something like this, but I can definitely see that some users will like this very much.

1 Like
10

Me neither, although I am a bit paranoid about exploits especially in games and image decoding software like ImageMagick so I’d much rather some sort of ACE bug leading to malware getting stuck inside an unprivileged sandbox than my host system where they can access all my files, etc

11

In this case, you can run AppImages in a sandbox like Firejail.

12

Yeah, but then return to the original issues of sandbox escape leading to privilege escalation, dealing with SUID binaries which requires root, no easy way to view the permissions, etc. And although aisap is nowhere near finished, I use it daily and it seems to work pretty well