Remove PGID PUID Limitations

[OdinVex]

Broken bind mount access for Syn&QTS even with PGID=0, PUID=0, 
MUMBLE_GID=0, MUMBLE_UID=0, /data:770 (normally 660) and owned (docker running under UID=0, GID=0, forced requirement). Why is every docker trying to force running as 1000:1000+ when you can let the end user do what they need? So much hand-holding...*sigh* Breaking usability.

/entrypoint.sh: line 77: /data/mumble_server_config.ini: Permission denied

[OdinVex]

Yes, I know I can build the Dockerfile. Why not just add a permissions correction into entrypoint to allow using PGID/PUID?

For now, I'm using this compose:


    command: |
      /bin/bash -c "groupmod -o -g 0 mumble; usermod -o -u 0 mumble; runuser mumble -g mumble -c '/entrypoint.sh /usr/bin/mumble-server -fg' 2>/dev/null"
    entrypoint: /bin/bash -c "/bin/bash -c \"$${@}\""
    environment:
      - PGID=0 # administrators
      - PUID=0 # admin
      - UMASK=000 # Leave permissions alone
    user: root # exec entrypoint as root (0:0) inside docker

It's to maintain share permissions correctly in Syn&QTS.

Edit: This was lazily put together, mind. The redundant shells were from tinkering and left over, I didn't bother to remove them.

[Krzmbrzl]

Why not just add a permissions correction into entrypoint to allow using PGID/PUID?

Could you elaborate on that?

Anyway, we'd be open to PRs to remedy this. There has not been a concrete reason to use these ids in particular - iirc that was essentially copied from elsewhere :shrug:

[OdinVex]

Why not just add a permissions correction into entrypoint to allow using PGID/PUID?

Could you elaborate on that?

Let the end user decide which PID and GID and even username that the Docker should use for Mumble for those that will use binding paths. This allows us to seamlessly maintain permissions. It's easier to restrict than to grant more permissions with Docker.

Anyway, we'd be open to PRs to remedy this. There has not been a concrete reason to use these ids in particular - iirc that was essentially copied from elsewhere 🤷

The change would need to be made in the entrypoint.sh. It needs to modify the mumble user and group permissions to whatever MUMBLE_UID and MUMBLE_GID are set to. It leaves them alone, which means they'll use whatever the Dockerfile used, which is 1000. Just maybe add a section at the beginning of the script to change the uid and gid of the user and chown the correct directories, then proceed the rest of the script. I built that ugly short-cut above to circumvent the Docker Image's pre-built limitation, for now.

[trymeouteh]

Asking on reddit, I got this as a working solution when using podman.

podman run --detach --name mumble-server --publish 64738:64738/tcp --publish 64738:64738/udp --volume /home/testing/Documents/MumbleServers:/data --restart on-failure --userns=keep=id mumblevoip/mumble-server

It seems to work, will --userns=keep=id be the proper way for the mumble-server container to adjust the UID and GID permissions for podman and docker?

[OdinVex]

Asking on reddit, I got this as a working solution when using podman.

podman run --detach --name mumble-server --publish 64738:64738/tcp --publish 64738:64738/udp --volume /home/testing/Documents/MumbleServers:/data --restart on-failure --userns=keep=id mumblevoip/mumble-server

It seems to work, will --userns=keep=id be the proper way for the mumble-server container to adjust the UID and GID permissions for podman and docker?

You're assuming people have access to the shell or process parameters of a non-Docker software. Wrong way to implement.

[trymeouteh]

You're assuming people have access to the shell or process parameters of a non-Docker software. Wrong way to implement.

How would one implement this using docker or podman to allow the volume permissions to remain unchanged for the host user?

[azlux]

Currently, the Docker image is build on a no-root user, so volume cannot be chmod/ chown. To fix this issue, we have two chooses :

• dynamic mapping of UID, supported by docker, used for the non-root docker installation. Not used into "standard" docker installation.
• Run an entrypoint as root, change the folder rights, then drop the privilege to run the mumble-server.

To do the second possibility, we need to refactor the Dockerfile and the entrypoint.sh script.

See an example make by plex

[azlux]

Why is every docker trying to force running as 1000:1000+ when you can let the end user do what they need? So much hand-holding...sigh Breaking usability.

We mostly use the 1000 ID because it's the first one proposed when your create a new user into a Unix system. ID 0 (root), shouldn't be used by a program.

Docker is quite a dirty man of security. It's not they goal, they use additional layer to do it. So it's a little bit inconvenient when you want to have a simple security layer. It all or nothing for them.

[OdinVex]

Why is every docker trying to force running as 1000:1000+ when you can let the end user do what they need? So much hand-holding...sigh Breaking usability.

We mostly use the 1000 ID because it's the first one proposed when your create a new user into a Unix system. ID 0 (root), shouldn't be used by a program.

Docker is quite a dirty man of security. It's not they goal, they use additional layer to do it. So it's a little bit inconvenient when you want to have a simple security layer. It all or nothing for them.

Running as non-root in a Docker is just security through obscurity. But that comment wasn't meant about people who decide to use security through obscurity, it was meant as in 'why are developers preventing others from running as they wish?' If I want to rm -rf / that's my business.

[azlux]

Why is every docker trying to force running as 1000:1000+ when you can let the end user do what they need? So much hand-holding...sigh Breaking usability.

We mostly use the 1000 ID because it's the first one proposed when your create a new user into a Unix system. ID 0 (root), shouldn't be used by a program. Docker is quite a dirty man of security. It's not they goal, they use additional layer to do it. So it's a little bit inconvenient when you want to have a simple security layer. It all or nothing for them.

Running as non-root in a Docker is just security through obscurity. But that comment wasn't meant about people who decide to use security through obscurity, it was meant as in 'why are developers preventing others from running as they wish?' If I want to rm -rf / that's my business.

Because the first part of run will start as root, so the entrypoint need to be carefully write until we drop the privileged. We didn't saw the lack flexibility with our implementation before, making hard to used on synology. I agree with adding this feature

[OdinVex]

Why is every docker trying to force running as 1000:1000+ when you can let the end user do what they need? So much hand-holding...sigh Breaking usability.

We mostly use the 1000 ID because it's the first one proposed when your create a new user into a Unix system. ID 0 (root), shouldn't be used by a program. Docker is quite a dirty man of security. It's not they goal, they use additional layer to do it. So it's a little bit inconvenient when you want to have a simple security layer. It all or nothing for them.

Running as non-root in a Docker is just security through obscurity. But that comment wasn't meant about people who decide to use security through obscurity, it was meant as in 'why are developers preventing others from running as they wish?' If I want to rm -rf / that's my business.

Because the first part of run will start as root, so the entrypoint need to be carefully write until we drop the privileged. We didn't saw the lack flexibility with our implementation before, making hard to used on synology. I agree with adding this feature

Not just Synology/Qnap, but in general any Docker. A simple fix, yeah. Run as PGID/PUID and Docker's user var.

[trymeouteh]

It would be great to have an update on the docker image to allow it to work easily with docker and podman and have the volume permissions be no different when running a mumble via debian apt package

[yllekz]

Are there PUID and PGID variables we can use in this? I just tried this container and it failed out with a permissions error. It should have PUID and PGID variables like the linuxserver containers do.

[OdinVex]

Are there PUID and PGID variables we can use in this? I just tried this container and it failed out with a permissions error. It should have PUID and PGID variables like the linuxserver containers do.

Answer is in the thread...did you miss the entire thread? :/

[maxhambraeus]

Maybe this problem and a solution should be added to the "common problems" section in the README?

Edit: I stumbled across this and it says to chown -R 1000 data/ which ended up working for me. Maybe this should be written somewhere more clearly?

[yllekz]

Are there PUID and PGID variables we can use in this? I just tried this container and it failed out with a permissions error. It should have PUID and PGID variables like the linuxserver containers do.

Answer is in the thread...did you miss the entire thread? :/

Having to dig through multiple layers of posts, replies and quotes is difficult to parse and this should be in the documentation or in an example docker compose file. Please do not punch down.

[OdinVex]

Are there PUID and PGID variables we can use in this? I just tried this container and it failed out with a permissions error. It should have PUID and PGID variables like the linuxserver containers do.

Answer is in the thread...did you miss the entire thread? :/

Having to dig through multiple layers of posts, replies and quotes is difficult to parse and this should be in the documentation or in an example docker compose file. Please do not punch down.

It was not a punch down, it was a fish-slap. People that don't read threads but then try to make comments asking for the very information in the thread just wastes everyone's time and is an insult to those that took the time to contribute and post.

[farmergreg]

I ended up reading this thread because my server stopped working.

Here is what I did:

I was setting MUMBLE_UID and MUMBLE_GID to 1000 in my docker-compose.yml. I removed these lines. Next, I changed the permissions on my mount point to chown 10000:10000. This matches the UID/GID that is set in the Dockerfile when this image is built.. That aligned the permissions correctly so that I no longer received the "/entrypoint.sh: line 77: /data/mumble_server_config.ini: Permission denied" error.

[OdinVex]

I ended up reading this thread because my server stopped working.

Here is what I did:

I was setting MUMBLE_UID and MUMBLE_GID to 1000 in my docker-compose.yml. I removed these lines. Next, I changed the permissions on my mount point to chmod 10000:10000. This matches the UID/GID that is set in the Dockerfile when this image is built.. That aligned the permissions correctly so that I no longer received the "/entrypoint.sh: line 77: /data/mumble_server_config.ini: Permission denied" error.

That works for you because you're fine with your host files being chowned by user 10000 under group 10000. Those of us wanting this changed do not. (You meant chowned, by the way.)

[OdinVex]

For those thinking "just chown/chmod it": Some might prefer to control ownership and access to files to better help secure them, especially on shared servers or when simply locking down a server from unauthorized changes mitigating damage done by compromised users.

[azlux]

Here the change we need to do on the entrypoint. This way we can se any UID/GUID possible and run mumble with it with gosu (https://packages.debian.org/bookworm/gosu). It's also possible to run as '0' (root) if needed.

#!/bin/bash

MUMBLE_UID=${MUMBLE_UID:-10000}
MUMBLE_GID=${MUMBLE_GID:-10000}

if [ "MUMBLE_UID" != "0" ]; then
  groupmod -og "$MUMBLE_GID" mumble
  usermod -ou "$MUMBLE_UID" mumble
  chown -R mumble:mumble /data && chown -R mumble:mumble /etc/mumble
  exec gosu mumble "$@"
fi
exec "$@"

[OdinVex]

I'd only alter the user and let the user chown/chmod the files as they wish. They may be using shared directories with different permissions for any reason. Edit: I don't see any need for gosu at all. runuser is already used.

[azlux]

Is https://github.com/mumble-voip/mumble-docker/pull/43 good for your usages ?

[OdinVex]

Is #43 good for your usages ?

Edit: Why would it change things? It's not using PGID and PUID, it's using MUMBLE_GID and MUMBLE_UID. I also just stopped using Mumble to begin with, decided on using the Matrix protocol instead.

[farmergreg]

i didn't try it out, but i did review the code changes in #34. i think it make my use case much better. thanks!

[GamerKingFaiz]

I was able to solve this for myself using Portainer. In Advanced Container Settings, under the Commands & logging tab, set the User field to whatever user you want to set (e.g. for me I set 1000:1000). Thanks to this Reddit comment!

But it would be lovely if someone made it so that there were PUID & PGID env variables we could just set. It seems like the standard set by linuxserver (https://docs.linuxserver.io/general/understanding-puid-and-pgid/).

[OdinVex]

I was able to solve this for myself using Portainer. In Advanced Container Settings, under the Commands & logging tab, set the User field to whatever user you want to set (e.g. for me I set 1000:1000). Thanks to this Reddit comment!

But it would be lovely if someone made it so that there were PUID & PGID env variables we could just set. It seems like the standard set by linuxserver (https://docs.linuxserver.io/general/understanding-puid-and-pgid/).

PUID and PGID are (edit: already) able to be set, the internal user for 'mumble' is 1000:1000 though, so you either need to hijack the entrypoint to adjust the passwd/group files or you can use a different user for the docker via user: root/user: 0:0 (which is what you did but through Portainer's UI). This "protect you from yourself" crap is what I'm bitching about. I'm so sick of "you're logged in as an administrator, but we're going to make you use sudo every time" bullshit, it's exhausting dealing with it all. Want to use Dolphin to browse a root-owned folder that doesn't have o+x? Slag off, not happening. Try to sudo around that, nope, not happening. Forced to resort to shells just to browse a folder because of some "no, you shouldn't be allowed to chew meat, only applesauce" bullshit (Mark Twain reference).