/etc/services.d/bazarr/run is no longer marked as executable, breaking s6 read-only root
Avamander opened this issue · 11 comments
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:
- kubeflow/kubeflow#5808 (comment)
- rocker-org/rocker#202
- containers/podman#3803
- Radarr/Radarr#5300
- linuxserver/docker-radarr#113
- just-containers/s6-overlay#158
- linuxserver/docker-homeassistant#54
- linuxserver/docker-radarr#181
- linuxserver/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"
Bro chill, we got it.
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.
@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.
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
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?
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.
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?
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.
Unstale.
I still semi-manually fix the containers by chmoding inside the containers. A proper fix would be appreciated.
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.