Script cannot start as user minecraft (999)

[cyberops7]

The change to the script to run as the minecraft user (instead of root) is a good idea, but since the minecraft user is not created in the Dockerfile, if you try to have the container run as user 999 (which appears to be the UID of the minecraft user created by the startup script), the script fails at line 85 since that user does not exist (since it is not running as user 0, it skips the creation of the minecraft user), giving this error:

whoami: cannot find name for user ID 999

The Dockerfiles need to be updated to create the minecraft user, and could really just have the user set to minecraft at the end of the script, something like this (I have not tested it yet):

RUN useradd -m -r -u 999 -g 999 -s /bin/bash minecraft
...
USER minecraft

Sidebar: I find it a bit odd to create a system user (the -r flag) but then give it a shell (the -s flag) since usually system users wouldn't get a shell (but this is how the startup script currently does it, with -r and -s). What is the reason for creating this as a system account, vs a regular account and ending up with a UID > 1000? I just added the -u and -g flags in the example code to be explicit.

[cyberops7]

At least, that is the error I get when I tried to update my kubernetes manifests for this with:

     securityContext:
       runAsUser: 999
       runAsGroup: 999

[cyberops7]

A downside to this is that now the process to take ownership of all the files happens twice...once when it creates the minecraft user, and then again when it restarts and gets to the main step where it takes ownership of all files (where it throws an error if you try to actually run the container as user 999).

I'll circle back soon and submit a PR for this as well if no one else gets to it.

[cyberops7]

Man, this is a bit of a rabbit hole...the way this was implemented in the recent PR that got merged is not ideal, and now has everyone's files owned by 999:999, so we kind of need to stick there. To actually get this done what I would consider the "right" way, where it is also compatible with people's servers that are currently running as root, it is a bit more involved.

Also, a side effect of running the container as a non-root user (which is a best practice) the idea of taking ownership of all files inside the directory may not work as expected, since that will execute as a non-root user now, so if root owns anything, that won't be able to be changed.

[cyberops7]

I've been working on this, plus tweaking the majority of startup script as part of it...so I'll have a good-sized PR coming soon.