chmod 1777 has surprising behaviour

The following cost me hours of debugging. It's a side effect of https://github.com/docker-library/php/pull/1383 plus https://sysctl-explorer.net/fs/protected_symlinks/ .

Dockerfile:

FROM php:8.1-apache

RUN mkdir /tmp/files
RUN ln -s /tmp/files myfiles

Commands:

$ podman build -t symtest -f Dockerfile .
$ podman run --userns=keep-id --rm --name symtest-container -it symtest bash

podman is basically the same as docker; --userns=keep-id just makes it so everything runs as the user running the command in the container, so in this case I was running with UID 1086.

In the container:

rlpowell@85b62d863dde:~$ ls -l myfiles
lrwxrwxrwx. 1 root root 10 Dec 13 20:16 myfiles -> /tmp/files
rlpowell@85b62d863dde:~$ ls -l /tmp/files/
total 0
rlpowell@85b62d863dde:~$ ls -l myfiles/
ls: cannot access 'myfiles/': Permission denied

I discovered this because https://github.com/wikimedia/mediawiki-docker has symlinks from /var/log/apache2/error.log to /dev/stderr (and a few other similar ones) that with this php docker image change, cause apache to fail to run if the running UID is not the same as whatever the default for www-data is (33 I think?) because /var/log/apache2 is 1777 and own by that ID.

I don't have any particular suggestions for how to solve this because I'm not sure what problem you were trying to solve by making this change in the first place.

Reproduce the behavior from the issue's Dockerfile and podman commands, then inspect the linked PHP image change and the protected_symlinks documentation. Check the /var/log/apache2 symlink scenario described in the report. Done requires identifying the cause and agreeing on a safe, specific change or documentation outcome.