/etc/services.d/bazarr/run is no longer marked as executable, breaking s6 read-only root

[Avamander]

Note: Quite a few linuxserver containers broke like this relatively recently

Expected Behavior

The file "/root/etc/services.d/bazarr/run" is no longer marked executable in the container, configurations utilizing S6_READ_ONLY_ROOT and what mark the root read-only will fail. This is a regression compared to the previous builds.

Current Behavior

The ./run file of the bazarr service is rw-rw-r-- instead of rwxrw-r-- causing the following error message:

bazarr     | s6-supervise bazarr (child): fatal: unable to exec run: Permission denied
bazarr     | s6-supervise bazarr: warning: unable to spawn ./run - waiting 10 seconds

One chmod in the container fixes that.

Steps to Reproduce

Add the snippet provided below to your compose file.

Similar symptoms or issues:

• Jupyterlab, Rstudio and VSCode do not run as non root in Kubeflow 1.8 kubeflow/kubeflow#5808 (comment)
• Centos repos have version of Docker that cannot run init as default command rocker-org/rocker#202
• Always mount tmpfs with noexec containers/podman#3803
• [Docker:nightly] unable to exec run: Permission denied Radarr/Radarr#5300
• Permission denied error after latest update docker-radarr#113
• ERGURNT: s6-overlay failed to start service on docker-1.10.3 just-containers/s6-overlay#158
• /etc/services.d/homeassistant/run is no longer marked as executable, breaking s6 read-only root docker-homeassistant#54
• /etc/services.d/radarr/run is no longer marked as executable, breaking s6 read-only root docker-radarr#181
• /etc/services.d/jackett/run is no longer marked as executable, breaking s6 read-only root docker-jackett#126

Environment

OS: Ubuntu 22.04
CPU architecture: arm64
How docker service was installed: Official repos

Command used to create docker container

    read_only: true
    tmpfs:
      - /run:rw,exec
      - /tmp:rw,noexec,nosuid
    environment:
      - "S6_READ_ONLY_ROOT=1"

[github-actions]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[Roxedus]

Bro chill, we got it.

[aptalca]

The run files were never marked as executable in our images. S6 v2 handled them correctly. S6 v3 expects them marked executable, which our baseimage corrects during init. But I'm guessing that all those extra compose arguments and vars you're adding (for whatever reason) are interfering with that process. Remove those and it will work as expected. In other words, we never supported your custom config so there is no regression as far as we're concerned. It all works fine with the sample compose yaml we provide.

[Avamander]

@aptalca Well it shouldn't be hard to mark the run files executable so that there's no need for that during init. Alternatively, the baseimage could follow S6_READ_ONLY_ROOT and mark it executable in the correct location.

There's no need to guess, it is very likely the cause because the container is R/O so nothing can be corrected too late. The reasons for enforcing immutable infrastructure are many - clustered setups, no hidden state and better security. I also wouldn't say that you didn't support, it's just that now it's broken and there's barely any reason for it to be so.

[aptalca]

Well it shouldn't be hard to mark the run files executable

not hard?? yeah, because you're not the one who has to PR hundreds of repos, babysit the builds and do the reviews and merges.

Alternatively, the baseimage could follow S6_READ_ONLY_ROOT and mark it executable in the correct location.

Baseimage already marks them executable in the correct location. That's why it works for everyone else.

there's barely any reason for it to be so

We disagree

[Avamander]

@aptalca

not hard?? yeah, because you're not the one who has to PR hundreds of repos, babysit the builds and do the reviews and merges.

Just like the switch to S6 v3, it might be time-consuming, but not hard. A fix would be quite universal.

Baseimage already marks them executable in the correct location. That's why it works for everyone else.

Well it doesn't, S6_READ_ONLY_ROOT being set means that only modifications after being created should be done in the /run tmpfs. Plus like, it really doesn't work for anyone else who wishes to run linuxserver containers in more complex environments.

We disagree

I don't understand the negative attitude, it's one octet to modify in Dockerfile. Would you accept a few PRs to fix this?

[Roxedus]

This is not fixable in the baseimage unfurtunatly, thats where the time comes in. The current handling is to let s6 mark these as executable on boot.

[Avamander]

@Roxedus

This is not fixable in the baseimage unfurtunatly, thats where the time comes in.

Hmm. But in theory the part that instructs S6 to mark these as executable could in theory be updated to follow S6_READ_ONLY_ROOT and mark these as executable in just other directory?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Avamander]

Unstale.

I still semi-manually fix the containers by chmoding inside the containers. A proper fix would be appreciated.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.