Add PUID and PGID env option for Portainer compatibility about papermc-docker HOT 18 CLOSED

It runs the container as root even if you specify another user under Advanced container settings > Command & logging?

from papermc-docker.

I tried this, but you can only use users there that are inside the passwd file inside the container, not the host sadly.

from papermc-docker.

Alright, the container doesn't exactly have a proper user yet, so that needs to be implemented first or simultaneously. I'll look into this later.

from papermc-docker.

I don't know about Portainer, but I just created a pull request to run this as a non-root user, and you can specify the PUID/PGID as environmental variables.

from papermc-docker.

I was looking into this again after receiving the pull request, and... can you do this by specifying the Docker -u or --user option in Portainer's "Command" field under "Commands and Logging"? Portainer's documentation is... mostly nonexistent from what I can tell, but this seems to imply that you can. Also, Docker's documentation mentions that while using names with this option requires the user and/or group to exist within the container, using numeric IDs does not; have you tried using a numeric PUID and/or PGID in the "User" field?

from papermc-docker.

A benefit is that it will run as not-root, even if you do nothing else. If you really need root, you can set the EVs to 0.

But, it allows some of the items to be done as root, like the initial permissions, etc, prior to passing off the networked services to a standard user. I'm not sure of all the reasons, but I never see the --user flag used over setting EVs for PUID/GUID.

from papermc-docker.

This image has absolutely no need for root permissions. The default user can be changed to a non-root user by using USER in the Dockerfile. The only reason to add these environment variables would be to be compatible with Portainer or other third-party software. I'm trying to ascertain whether or not this is necessary, since any method of adding these environment variables will clearly be a bit complicated.

from papermc-docker.

Do you have it published anywhere that people would use it without modifying the Dockerfile and building it themselves?

from papermc-docker.

Yes, Docker Hub. Link is also at the bottom of README.md.

To be clear, I'm not suggesting that users add USER to the Dockerfile, I'm suggesting that I do that if a more complicated solution is not necessary. A one line addition to the Dockerfile is a much better solution, if it works. And if we were only concerned about pure Docker usage, it would work.

from papermc-docker.

This way allows the end user to map that user to something that exists on their system, that can have who knows what permissions or whatever. If you add it, you'd have to pick a high gid/sid, so that it doesn't map to some silly local account on whatever host they're running, and then the user would have to create something to match what you've chosen.

What you're describing works fine for personal/non-shared use, but the added complexity (which, isn't too bad, we just check if our container users exists, if it doesn't we create it, with either a supplied UID/GID, or a placeholder (9001)) exists to make it extensible elsewhere.

The parts where we're changing ownership are just there for convenience if people do something silly, like pre-create the folder, or copy backups of the folder and start the container.

from papermc-docker.

You can set the UID and GID to a valid UID and GID from the host with the -u or --user option of docker run. That's literally what the request is in this issue, they want to avoid having to chown to modify files in the volume via the host system. I believe the user should be responsible for setting their permissions correctly; I don't want to restrict how this image can be configured on assumptions about the use case. Also, I don't think that fixing simple, non-destructive user errors is worth requiring "root" permissions in a container for a Minecraft server.

from papermc-docker.

/shrugs. I just downloaded this because it used the v2 Paper API. By default, it ran as root and this issue existed.

from papermc-docker.

If it's needed for popular third-party software to work with this, I am willing to do it your way. I just want to stick to Docker's intended usage if possible. I'm sorry for being a bit rude. If we end up sticking with USER and -u/--user, you're still free to maintain, publish, and use your fork.

from papermc-docker.

It looks like --user is newer, but the EVs for for PUID/PGID are still in pretty widespread use, like all of the Linuxserver.io packages, and some things were designed to expect it, as it became a "standard" pre--user. The newer, newer route is running docker in non-privileged mode entirely, but that is just out of experimental stages.

The best route these days, since you can't know how users are running things, might be to check in the entrypoint if it is running as root, and if so, then do the stuff to not do that. That could be made to work with PUID/PGID EV's, the --user flag, non-privileged mode, and fallback to being 'safer' for people doing none of those. But, you know... more IFs!

from papermc-docker.

As I understand it, if USER is specified with a non-root user in the Dockerfile, the container will not run as root unless the user specifically runs it as root with -u/--user, at which point it is clearly intentional and should be allowed (in my opinion). I'll test this with Portainer myself soon, since it seems like OP might not be watching this issue anymore.

from papermc-docker.

I'm not quite sure to understand what the discussion concluded
Could we have a way to specify the user please?

• PUID/PGID in environment variables is what comes to my mind, has https://www.linuxserver.io/ (they are maintaining community images) uses it as well as a lot of popular images.
• If the -u option works why not, as long as you can use it in a docker-compose file.

from papermc-docker.

Conclusion: -u works fine for normal Docker usage, but the user who originally opened this issue was having difficulties making this work with Portainer. I don't have a Portainer installation set up to test this on. I was going to set one up to try a few solutions which use the -u option, but I honestly forgot and got sidetracked with more important IRL stuff. The main reason I want to avoid the PUID/PGID thing is because it requires some weird permission-juggling which means that, technically, the initial execution of the container has to have "root" permissions anyway, therefore not resolving any security concerns.

To be clear, -u works right now if you're using Docker or Docker Compose directly. It is a built-in feature of Docker itself. The only change necessary if we stick with that is to change the default user to a non-root user with a USER line in the Dockerfile. If I can verify that there is a way to set the -u option in Portainer, I will make that change and close this issue.

from papermc-docker.

Apologies for not responding for years. See #74 for what happened.

If Rancher and/or Portainer still haven't updated to use Docker's official method for setting the container's user, feel free to reopen the issue, but I'm closing it as not planned for now.

from papermc-docker.