Hey there, let's break down how to lock down your Minecraft servers (Spigot/ForgeServer) running in Docker so plugins can't write to your host's root directory. This is all about layered security—from Docker configuration to Java-level restrictions.

1. Stop Mounting the Host's Root Directory (Critical!) #

First, double-check your Docker run command or docker-compose.yml. If you've accidentally mounted the host's / directory into the container (like -v /:/host-root), that's the biggest red flag. This gives the container full access to your host's filesystem, so remove any such mounts immediately.

Only mount specific, necessary directories (like your server's world data, plugin configs) instead of the entire root. For example:

docker run -v /home/your-user/mc-server-data:/home/mcserver/data your-mc-image

2. Run the Server as a Non-Root User #

By default, Docker containers run processes as root, which gives plugins way too much power if they escape the app sandbox. Create a dedicated non-root user in your Dockerfile to run the server:

# Add a non-root user
RUN useradd -m mcserver
# Switch to this user
USER mcserver
# Set working directory to the user's home
WORKDIR /home/mcserver

When you run the container, ensure you're using this user (the Dockerfile's USER directive handles this, but you can also enforce it with -u mcserver in your docker run command). Now, even if a plugin tries to write to /, it'll hit permission denied since the user doesn't have root access.

Bonus: Make the Container's Root Filesystem Read-Only #

Take this a step further by running the container with a read-only root filesystem. You'll just need to mount specific directories as writable for the server's data:

docker run --read-only \
  -v /home/your-user/mc-server-data:/home/mcserver/data \
  -u mcserver \
  your-mc-image

This blocks any writes to the container's root filesystem entirely—plugins won't be able to create files like /test.cpp at all.

3. Restrict Linux Capabilities with Docker #

Docker containers inherit a set of Linux capabilities by default (like the ability to modify filesystem permissions). Drop all unnecessary capabilities to limit what the container can do:

docker run --cap-drop all --cap-add NET_BIND_SERVICE \
  --security-opt=no-new-privileges \
  your-mc-image

• --cap-drop all removes all capabilities, then --cap-add NET_BIND_SERVICE adds back only the one needed to bind to network ports (for the server).
• --security-opt=no-new-privileges prevents the server process from gaining additional privileges (via sudo or su, for example).

4. Use Java Security Manager (Java-Level Restriction) #

Since Spigot and Forge are Java applications, you can use the Java Security Manager to enforce fine-grained filesystem access rules for plugins. Create a policy file (e.g., mc-security.policy) with rules like:

grant codeBase "file:/home/mcserver/plugins/-" {
    // Allow plugins to write to the server's data directory
    permission java.io.FilePermission "/home/mcserver/data/-", "read,write,delete";
    // Deny any writes to the root directory or specific malicious files
    permission java.io.FilePermission "/-", "read";
    permission java.io.FilePermission "/test.cpp", "write", "deny";
};

Then start the server with the security manager enabled by adding these JVM arguments:

java -Djava.security.manager -Djava.security.policy==mc-security.policy -jar spigot.jar

This will block plugins from writing to restricted directories, even if they have some container-level access. Note: You may need to adjust the policy for legitimate plugins that require specific access—test with your plugin set first.

5. Audit and Trust Only Verified Plugins #

Last but not least, prevent malicious plugins from being installed in the first place:

• Only download plugins from trusted sources (SpigotMC's official plugin repository, CurseForge for Forge mods).
• Avoid using unmaintained or unknown plugins—check reviews and update history.
• Regularly update plugins to patch any security vulnerabilities.

内容的提问来源于stack exchange，提问作者Tristan Ochs