Support AppImages using zstd compression

[Eckoa]

Description

Trying to run the latest RPCS3 appimage in firejail it fails to run with a mount failure. I looked at line 188 that the output said was the issue in appimage.c and realized that it was thinking its iso9660 and not squashfs. I double checked by extracting the appimage and it does in fact produce an squashfs-root

I havent found a way in the documentation/appimage.c to tell it the appimage type so i figured it would be best to report this here.

bash-5.2$ firejail --appimage rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage
Reading profile /etc/firejail/rpcs3.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-xdg.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-run-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
firejail version 0.9.74

Parent pid 6630, child pid 6634

** Warning: dropping all Linux capabilities and setting NO_NEW_PRIVS prctl **

Mounting appimage type 1
Error ../../src/firejail/appimage.c:188: appimage_mount: mounting appimage: Invalid argument
Error: proc 6630 cannot sync with peer: unexpected EOF
Peer 6634 unexpectedly exited with status 1

Steps to Reproduce

run the latest RPCS3 appimage with the latest firejail

Expected behavior

application mounts and run

Actual behavior

fails to mount the appimage with invalid arguements

Behavior without a profile

produces the same output as above but without the profile loaded

Environment

• Kernel: Linux 6.15.7-cachyos1.fc42.x86_64 x86_64
• Linux distribution : Fedora 42
• Name/version of the relevant program(s)/package(s) : rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage
• Version of Firejail: firejail version 0.9.74

[Eckoa]

I had an idea of trying to repack RPCS3 and I figured out how to repackage the appimage

I think this isnt so much a firejail issue as an RPCS3 packaging issue. Repacking the appimage it runs just fine so if you would like ill close

EDIT: fouund the offending commit for RPCS3 RPCS3/rpcs3@2357072

They changed how its built and use zstd compression. Im not sure what might be causing the issue with firejail here

[kmk3]

Thanks for reporting this.

I had an idea of trying to repack RPCS3 and I figured out how to repackage
the appimage

I think this isnt so much a firejail issue as an RPCS3 packaging issue.
Repacking the appimage it runs just fine so if you would like ill close

EDIT: fouund the offending commit for RPCS3
RPCS3/rpcs3@2357072

They changed how its built and use zstd compression. Im not sure what might
be causing the issue with firejail here

bash-5.2$ firejail --appimage rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage
[...]
Mounting appimage type 1
Error ../../src/firejail/appimage.c:188: appimage_mount: mounting appimage: Invalid argument
Error: proc 6630 cannot sync with peer: unexpected EOF
Peer 6634 unexpectedly exited with status 1

The error is from L188 (type 1, iso9660):

• firejail/src/firejail/appimage.c

  Lines 173 to 196 in 3f2f201

  	// mount appimage into sandbox file system
  	void appimage_mount(void) {
  	if (!devloop)
  	return;
  	unsigned long flags = MS_MGC_VAL|MS_RDONLY;
  	if (getuid())
  	flags |= MS_NODEV|MS_NOSUID;
  	if (size == 0) {
  	fmessage("Mounting appimage type 1\n");
  	char *mode;
  	if (asprintf(&mode, "mode=700,uid=%d,gid=%d", getuid(), getgid()) == -1)
  	errExit("asprintf");
  	if (mount(devloop, RUN_FIREJAIL_APPIMAGE_DIR, "iso9660", flags, mode) < 0)
  	errExit("mounting appimage");
  	free(mode);
  	}
  	else {
  	fmessage("Mounting appimage type 2\n");
  	if (mount(devloop, RUN_FIREJAIL_APPIMAGE_DIR, "squashfs", flags, NULL) < 0)
  	errExit("mounting appimage");
  	}
  	}

From a quick glance, the code seems to look for an LZMA header to determine the
size / offset to then determine the appimage type:

• firejail/src/firejail/appimage.c

  Lines 102 to 106 in 3f2f201

  	// get appimage type and ELF size
  	// a value of 0 means we are dealing with a type1 appimage
  	size = appimage2_size(ffd);
  	if (arg_debug)
  	printf("AppImage ELF size %lu\n", size);

• firejail/src/firejail/appimage_size.c

  Lines 164 to 172 in 3f2f201

  	// look for a LZMA header at this location
  	unsigned char buf[4];
  	ret = pread(fd, buf, 4, size);
  	if (ret != 4)
  	return 0;
  	if (memcmp(buf, "hsqs", 4) != 0)
  	return 0;
  	return size;

So yes, the issue might be to be due to it using zstd compression.

Is this only done for RPSC3 or are there more appimages using zstd compresion?

There is likely a better way to determine the appimage type, but I'm not
familiar with this code.

For now, I agree that repackaging it to use a more commonly-supported
compression format would be a good idea for the sake of backwards
compatibility/wider tooling support, especially if the file size difference is
not that significant from the user's perspective.

For the long-term, it might be good support appimages with different types of
compression, so leaving this as an enhancement.

These seem to be related:

• Use zstd compression AppImage/AppImageKit#478
• add zstd compression AppImageCommunity/libappimage#158

[Eckoa]

So yes, the issue might be to be due to it using zstd compression.

Is this only done for RPSC3 or are there more appimages using zstd compresion?

I havent encountered any other appimages using it yet but I generally don't use many so I can't say how many do. I'm sure more may adopt it in the future for the space savings like RPCS3