stuartpb
commented
10 years ago yabawock/buildstep@8b47bc0 makes this part of the created image - I'm not wild about that approach. On the other hand, using root within the container to create a non-privileged user does seem like the only viable way. So yeah maybe this is an aspect of building.
So, to recap:
- The built-in user approach: make an unprivileged user within the container during app compilation, then set the app start script to run the app as that user (possibly allowing an override). This is being discussed as part of plushu/plushu-build-cedarish#1 right now, and it does currently seem like the best solution.
- Make a single unprivileged user like www-data(?) in the host environment as part of this plugin's
install, and make sure everything within the app's base will be executable by that. This requires more modifications to the host environment, and it has a lot of expectations about the app container (specifically requiring it to be compatible with this unprivileged host user).
Really, since it seems like the only user that can reliably jump cross-container boundaries, without specific foresight within the container regarding the uids and all, is root, it seems like the user-inside-the-container route is the only viable way to go. As such, it wouldn't be up to this plugin (this plugin can just keep executing with whatever user Docker decides).
progrium/buildstep#109 indicates there's some issue in PHP caused by running the apps as root (under "Known Quirks"), and that Heroku doesn't run apps as root.
This plugin could conceivably be altered to not run apps as root (although that would break enter-sandbox, so there'd have to be some thought around how to fix that).