yuzutech / kroki

Creates diagrams from textual descriptions!
https://kroki.io
MIT License
2.97k stars 224 forks source link

Docker container permission error #1766

Closed maxwai closed 2 weeks ago

maxwai commented 3 months ago

The gateway docker container (named "core") can't resolve the hostnames of the other helper container (mermaid, excalidraw, bpmn) because of permission errors with the default user.

When starting the container we get following error from the core container (formatted)

{
  "timestamp": "1722935824662",
  "level": "WARN",
  "thread": "main",
  "logger": "io.netty.resolver.HostsFileEntriesProvider$Parser",
  "message": "Failed to load and parse hosts file at /etc/hosts",
  "context": "default",
  "exception": "java.io.FileNotFoundException: /etc/hosts (Permission denied)
                at java.base/java.io.FileInputStream.open0(Native Method)
                at java.base/java.io.FileInputStream.open(Unknown Source)
                at java.base/java.io.FileInputStream.<init>(Unknown Source)
                at io.netty.resolver.HostsFileEntriesProvider$ParserImpl.parse(HostsFileEntriesProvider.java:192)
                at io.netty.resolver.HostsFileEntriesProvider$ParserImpl.parseSilently(HostsFileEntriesProvider.java:295)
                at io.netty.resolver.HostsFileEntriesProvider$ParserImpl.parseSilently(HostsFileEntriesProvider.java:284)
                at io.netty.resolver.DefaultHostsFileEntriesResolver.parseEntries(DefaultHostsFileEntriesResolver.java:146)
                at io.netty.resolver.DefaultHostsFileEntriesResolver.<init>(DefaultHostsFileEntriesResolver.java:65)
                at io.netty.resolver.DefaultHostsFileEntriesResolver.<init>(DefaultHostsFileEntriesResolver.java:58)
                at io.netty.resolver.HostsFileEntriesResolver.<clinit>(HostsFileEntriesResolver.java:28)
                at io.netty.resolver.dns.DnsNameResolverBuilder.<init>(DnsNameResolverBuilder.java:67)
                at io.vertx.core.impl.resolver.DnsResolverProvider.<init>(DnsResolverProvider.java:105)
                at io.vertx.core.impl.resolver.DnsResolverProvider.create(DnsResolverProvider.java:43)
                at io.vertx.core.spi.resolver.ResolverProvider.factory(ResolverProvider.java:40)
                at io.vertx.core.impl.AddressResolver.<init>(AddressResolver.java:78)
                at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:220)
                at io.vertx.core.impl.VertxBuilder.vertx(VertxBuilder.java:229)
                at io.vertx.core.impl.launcher.commands.ClasspathHandler.create(ClasspathHandler.java:114)
                at io.vertx.core.impl.launcher.commands.BareCommand.startVertx(BareCommand.java:284)
                at io.vertx.core.impl.launcher.commands.BareCommand.run(BareCommand.java:192)
                at io.vertx.core.impl.launcher.commands.RunCommand.run(RunCommand.java:246)
                at io.vertx.core.impl.launcher.VertxCommandLauncher.execute(VertxCommandLauncher.java:248)
                at io.vertx.core.impl.launcher.VertxCommandLauncher.dispatch(VertxCommandLauncher.java:402)
                at io.vertx.core.impl.launcher.VertxCommandLauncher.dispatch(VertxCommandLauncher.java:346)
                at io.vertx.core.Launcher.main(Launcher.java:45)"
}

Looking at the permission of the file we can see that only root can read that file and the default user (kroki) can't read that file:

root@a8e4ba3069ab:/# ls -la /etc/hosts
-rw-r-----+ 1 root root 198 Aug  6 09:17 /etc/hosts

Since the file is not readable by the user running in the docker container, the application can't resolve the hostname of the other docker container.

ggrossetie commented 3 months ago

Hey! I guess we could add read permission to other (644) when building the Docker image. I'm not a security expert but I think it's fine to make that file readable from the main process.

FibreFoX commented 3 weeks ago

@maxwai How are you creating this container? I can not see how the permissions are non-readable from the kroki user.

When creating a new throw-away container via docker run --rm -it --entrypoint /bin/bash yuzutech/kroki and then listing the permissions, they look fine for me:

PS C:\> docker run --rm -it --entrypoint /bin/bash yuzutech/kroki
kroki@e19a041af801:/$ ls -althr /etc/hosts
-rw-r--r-- 1 root root 174 Nov  1 09:28 /etc/hosts
kroki@e19a041af801:/$

Can you show me how to reproduce your scenario?

I even checked the source container image eclipse-temurin:17.0.12_7-jre-noble where these permissions are coming from, nothing wrong there either.

maxwai commented 3 weeks ago

@FibreFoX I just tried on a different machine I get the permissions that you wrote.

When trying on the original machine (even if deleting the local image and making a fresh pull), the file has different permissions:

root@97517623080c:/# ls -la /etc/hosts
-rw-r-----+ 1 root root 174 Nov  5 10:14 /etc/hosts
root@97517623080c:/# getfacl /etc/hosts
getfacl: Removing leading '/' from absolute path names
# file: etc/hosts
# owner: root
# group: root
user::rw-
group::rwx                      #effective:r--
group:996:rwx                   #effective:r--
mask::r--
other::---

The GID 996 is a group of the host system that docker shouldn't have, so I actually don't know how it got that one.

FibreFoX commented 3 weeks ago

@maxwai Have you checked your /etc/docker/daemon.json file? Maybe there is something special configured. Or do you mount the hosts file to the container? Are you running "rootless docker"?

As far as I can see, there is no permission error in the published docker images, which seems to be confirmed as you have everything working "as expected" on the different machine.

maxwai commented 2 weeks ago

Closing this as the problem is with the host and not the image