fr24feed operation not permitted

[optiz0r]

Seems to be an issue in 1.0.46-2_linux_amd64_nohealthcheck, not present in 1.0.46-2_linux_amd64_nohealthcheck where /usr/local/bin/fr24feed cannot be executed.

This originally manifested as repeating error in stdout:

2024-02-22T21:15:40.173261318+00:00 stdout F [2024-02-22 21:15:40.173][fr24feed] qemu-arm-static: /usr/local/bin/fr24feed: Invalid ELF image for this architecture

On further investigation, this was nothing to do with arm or invalid ELF images, but because the s6 scripts/fr24feed naively assumes that if /usr/local/bin/fr24feed --version doesn't run, it should try again with qemu-arm-static. Since the binary cannot be exec'd, the --version test fails, and the script incorrectly tries to launch an amd64 ELF binary with qemu-arm-static wrapper.

The simplest reproduction case demonstrating the issue:

Broken in 1.0.46-2_linux_amd64_nohealthcheck

[root@crow ~]# podman run -ti --entrypoint /usr/local/bin/fr24feed ghcr.io/sdr-enthusiasts/docker-flightradar24:1.0.46-2_linux_amd64_nohealthcheck --version
{"msg":"exec container process `/usr/local/bin/fr24feed`: Operation not permitted","level":"error","time":"2024-02-22T21:40:01.397735Z"}

Working in 1.0.46-1_linux_amd64_nohealthcheck:

[root@crow ~]# podman run -ti --entrypoint /usr/local/bin/fr24feed ghcr.io/sdr-enthusiasts/docker
-flightradar24:1.0.46-1_linux_amd64_nohealthcheck --version
1.0.46-1

Injecting strace into the latest image doesn't yield any interesting reason as to why the binary cannot be execve'd:

root@cbdd708c9c0a:/# strace -f /usr/bin/fr24feed
execve("/usr/bin/fr24feed", ["/usr/bin/fr24feed"], 0x7ffe73606cd8 /* 41 vars */) = -1 EPERM (Operation not permitted)
strace: exec: Operation not permitted
+++ exited with 1 +++

This is running on a host with selinux disabled, so is not an avc denial.

[lancer73]

I had exactly the same problem with the arm64 builds on a Raspberry Pi 5. Had to rollback to 1.0.44 for a working version.

[eanmclaughlin]

Just found a workaround for this - add the NET_RAW capability to your container. I'm not sure what's changed to require this.

I'm running via rootless Podman 4.9.4 on Debian

cc @jbrazio

[lancer73]

Just found a workaround for this - add the NET_RAW capability to your container. I'm not sure what's changed to require this.

I'm running via rootless Podman 4.9.4 on Debian

cc @jbrazio

Brilliant, got it running now as well. Debian Bookwork using podman on a Pi 5

[blueal]

I am also receiving a similar error:

2024-06-23T22:34:05.142820106-07:00 [2024-06-24 05:34:05.141][fr24feed] qemu-arm-static: /usr/local/bin/fr24feed: Invalid ELF image for this architecture
2024-06-23T22:34:05.167084885-07:00 [2024-06-24 05:34:05.166][fr24feed_check_traffic] [WARNING] Cannot check data flow because tcpdump fails to execute. Try adding NET_ADMIN and NET_RAW capabilities to your container
2024-06-23T22:34:05.169068157-07:00 [2024-06-24 05:34:05.168][fr24feed_check_traffic] tcpdump: eth0: You don't have permission to perform this capture on that device
2024-06-23T22:34:05.169092567-07:00 [2024-06-24 05:34:05.168][fr24feed_check_traffic] (socket: Operation not permitted)

If I change my the release tag from latest to 1.0.46-1_linux_amd64_nohealthcheck it works without a problem.

Unfortunately the implementation of docker I'm using doesn't support adding arbitrary capabilities at the moment, so rolling back updates is the only solution at the moment. Anything newer, such as any variation of latest does not work.

[kx1t]

Note that we are removing qemu from the build - this was a left-over from the time that FR24 didn't provide amd64/x86_64 binaries and we have to run their stuff in qemu.

As for tcpdump not running in your build - the fr24feed_check_traffic script is simply used for logging the number of processed messages to the docker logs. It's not critical for the execution of the script. You can control the checking interval with the WATCH_INTERVAL environment variable. In your case, you can switch it off by setting:

      environment:
          - WATCH_INTERVAL=infinity

I'll add some wording to the README to describe this work-around

thanks - kx1t

[kx1t]

One more thing -- I can't test this because I don't have a Pi5 to my disposal, but some arm64 binaries don't run natively on Pi5, because in many of the Pi5 Linux Kernel images, the Kernel Page Size is set to 16K. Several apps are only compatible with 4K Kernel Page Sizes. This could possibly be the cause of fr24feed not running on a Pi5

See here for a work-around (which is basically setting your Kernel Page Size to 4K on the Pi5)