Allow building sail to run PHP as root #677
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
Today, I tried running Sail in a rootless Podman container, and the experience was less-than-ideal. You might better recognize the class of issues as being similar to Docker Desktop - this would be precisely right: it's the same all over again.
The reason boils down to the follow: the image, as it is laid out currently, has its entrypoint running as root, and its main functionality (i.e. php) running as the sail user. This means that root inside the container is the host user I'm using to run the container, and sail is some random UID.
Some relevant supporting documentation and references to previous issues:
The proposed proof-of-concept patch simply allows setting the
$SUPERVISOR_PHP_USER
env variable to run PHP in the container as root. Users should be instructed about this by the "getting started" documentation, to avoid spending an evening figuring it out (or not) like I just did.In my opinion this is the only valid long-term solution for rootless containers, as:
sail
in the sail container) have an effective ("host") UID that will not in any case be able to access /var/www/html (i.e. the user's project files), regardless of the value of--userns
, if the files themselves are not chowned to this unprivileged by either Podman (U flag for bind mounts) or something running on the host. This is because root in the container is mapped to the user launching the container, and all other uids in the container are mapped to random junk host uids (usually >100000). It's simple to test this: open a root shell in a Sail container, and runtouch /var/www/html/example && chown sail:sail /var/www/html/example
; go on that directory outside the container, the UID will be some junk number. You can also runcat /proc/self/uid_map
inside the container to see the mappingThis will effectively make PHP have the permissions and capabilities of the launching user, which imho is the standard expectation for a dev environment. Furthermore, in a world where people don't just go around launching containers as root, this would also be a sensible default setting, but since the real world is the insurmountable single point of truth I won't advocate for that.
So, to recap: