search

itzg / minecraft-server-charts

MIT License
267 stars 142 forks source link

SecurityContext seems to be breaking bedrock #164

Open zepiaf opened 1 year ago

zepiaf commented 1 year ago

Hi, updating the chart to the latest version seems to be breaking filesystem access within the entrypoint script.

DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved UID=0 from match path
DEBU[0000] Resolved GID=0 from match path
Looking up latest version... /opt/bedrock-entry.sh: line 23: restify.err: Permission denied /opt/bedrock-entry.sh: line 23: restify.err: Permission denied /opt/bedrock-entry.sh: line 23: restify.err: Permission denied Updating permissions /opt/bedrock-entry.sh: line 161: permissions.json: Permission denied

Am I missing something here ?

Thanks for all the work :)

itzg commented 1 year ago

I added a question for @uhthomas on the PR. The group IDs don't seem right now that I'm looking again.

itzg commented 1 year ago

@zepiaf are there any particular values you applied to chart or just going with defaults?

zepiaf commented 1 year ago

Only default, I didn't try to go farther and ended up reverting.

As reverting to previous version is fixing, it's a mild issue :)

itzg commented 1 year ago

Odd. When I try the latest chart I get slightly different GID reporting at startup:

DEBU[0000] Using /data to match uid and gid             
DEBU[0000] Resolved UID=0 from match path
DEBU[0000] Resolved GID=2000 from match path
INFO[0000] Skipping uid/gid change since current user is not root
uhthomas commented 1 year ago

Is it just bedrock? I'm able to run the standard Minecraft instance fine with this security context.

As explained in the reply on the PR, the different groups are deliberate and shouldn't cause issues like this.

zepiaf commented 1 year ago

As mentioned, I suspect it is the problem, however I did not push investigation too far, would be good to see if someone else has the problem deploying the chart. Might be a conflict with something else on my cluster. But hey, you know the rule, last PR always get the blame ;)

zepiaf commented 1 year ago

Is it just bedrock? I'm able to run the standard Minecraft instance fine with this security context.

As explained in the reply on the PR, the different groups are deliberate and shouldn't cause issues like this.

I'm only running bedrock, no idea for java

zepiaf commented 1 year ago

Odd. When I try the latest chart I get slightly different GID reporting at startup:


DEBU[0000] Using /data to match uid and gid             

DEBU[0000] Resolved UID=0 from match path

DEBU[0000] Resolved GID=2000 from match path

INFO[0000] Skipping uid/gid change since current user is not root

I'll try to deploy with the stock values later on a new namespace to double check, now that you mention it, it's weird indeed.

eddedre commented 8 months ago

I'm having the same issue with stock values. Is there a temp workaround? I noticed that this only happens when using a PVC

itzg commented 8 months ago

Perhaps try using the Java image in bedrock mode

https://docker-minecraft-server.readthedocs.io/en/latest/misc/examples/#bedrock-compatible-server

soekul commented 6 months ago

I encountered this error on a fresh setup w/ a pre-created PV at which I pointed the PVC. In my case I just needed to chown 1000 . on the underlying mount point.