Privileged actions on startup

[hughbris]

Preamble: I post this with some trepidation for a couple of reasons:

• I don't know exactly how to classify it or where it should live (issues, feature requests);
• I could very well be missing something and it's easily answered and no kind of issue, or it's a Docker thing.

I think this has been touched on but not answered in a way that helps my situation.

Context: I have derived a flat file CMS image from the upcoming FrankenPHP variation after a few failed attempts in the past, including with a couple of the other variants on offer. This is awesome, I'm pumped! I'm very keen to migrate my package to this base eventually (hopefully soon).

I'm getting there, I promise.

Problem: With no volumes or mounts of any kind, containers stand up and run pretty nicely it seems. I tend to use bind mounts exclusively because I find named volumes a PITA for development and git deployments. When I bind-mount existing host directories, no problems either. The problems start when I want to specify new bind mount directories and start containers.

(The environment is all Linux, FWIW.)

In simple terms, the containers exit because the required filesystems are created on the host with root permissions, and the directories required by the CMS can not be populated with files by a script on container start. As I've learned, this is Docker's documented behaviour for bind mounts, but not for named volumes – Docker creates any non-existing host directories with root privileges where a bind mount is specified. (I would love to know why the two types of persistent storage are initialised differently — there may be good reasons — but it seems it's just "by design" and we are left to shrug our shoulders.)

So the images work fine for existing install mount points but not when creating new ones.

My current images based off official php-fpm base images do not have this problem because the entrypoint script runs privileged. I do like that serversideup have found a way around that still allows me to change GID/UIDs, but I believe this to be the underlying cause of the problem here.

I've experimented a little with different initial host filesystem setups. The only direction I can offer to users to seed a new installation successfully, using my image, is to first create the bind-mounted directories on the host, then set their permissions to the user ID that the container runs as (83, 1000, whatever), and then bring the container up. When I do that, the mount points do get seeded correctly with the files required to run, and persist a working instance of the CMS. However, I don't think that's really a workable requirement or reasonable directive.

Possible suggestion: What would probably work around this without compromising container security is if I could run some commands (like permission setting) at startup. Would it be feasible to create another folder (like /entrypoint.d) or a file naming pattern where I can put startup scripts I want to run as root?

I hope I've been clear here. I'm open to any other suggested solutions or workarounds that don't affect image users' experience. Also happy to clarify anything because I would love to get this working under the new variant.

If this is reasonable, what process do you suggest I follow to progress it?