|
How would this be reproduced? We create the coder user as part of the image so it will always be the right user to remove: code-server/ci/release-image/Dockerfile Lines 37 to 38 in 53d981a If the user is not coder somehow, then these previous lines trying to rename it will fail anyway. code-server/ci/release-image/entrypoint.sh Lines 14 to 15 in 53d981a |
Sorry, something went wrong.
|
We create the coder user as part of the image so it will always be the right user to remove Okay, so now imagine the crazy hypothetical scenario where literally any part of that very specific scaffolding for this specific fork of the codebase provided by the outside environment changes, for any reason, like if, I dunno, the name of the company changed and you missed one or two extant references to it. |
Sorry, something went wrong.
|
Or rather, sorry, I guess I just don't understand how any of these variables are expected to work because there are zero usable comments here. The idea is that the line we're deleting isn't supposed to be deleting the user named by DOCKER_USER? How am I supposed to understand what this code's supposed to be doing? |
Sorry, something went wrong.
|
Here, I've updated the PR, here's a version where you can tell what cases would and wouldn't have bugs because the code actually describes what it's trying to do. |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks!
Okay, so now imagine the crazy hypothetical scenario
Yeah it would probably make sense for us to use the USER env var instead of hardcoding coder in case we ever change the user in the docker image and miss updating the entrypoint with the new name.
Sorry, something went wrong.
|
|
||
| if [ "${DOCKER_USER-}" ]; then | ||
| # Rename the `coder` user if a new name is specified by the `DOCKER_USER` environment variable | ||
| if [ "${DOCKER_USER-}" != "coder" ]; then |
There was a problem hiding this comment.
This will now run when DOCKER_USER is blank where before it would not, should probably be something like
Although, since we check if the user already exists below, it is probably not necessary to add this guard, but I suppose no harm in it either.
Sorry, something went wrong.
This way the DOCKER_USER variable won't accidentally retain sudoer permissions for any user not named coder (almost certainly a security hole).