Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running protoc-gen-kotlin as root fails with an error #73

Open
garyp opened this issue Jul 28, 2020 · 3 comments · May be fixed by #248
Open

Running protoc-gen-kotlin as root fails with an error #73

garyp opened this issue Jul 28, 2020 · 3 comments · May be fixed by #248
Labels
bug Something isn't working component-codegen help wanted Extra attention is needed

Comments

@garyp
Copy link
Collaborator

garyp commented Jul 28, 2020

Running protoc as root with the --kotlin_out option produces an error:

--kotlin_out: protoc-gen-kotlin: Plugin output is unparseable: \033[0;33mApplication
is running as root (UID 0). This is considered
insecure.\033[0m\nz\344w\n\031pbandk/google/api/http.ktz

This is because pbandk uses Spring Boot's launchScript feature in order to turn protoc-gen-kotlin.jar into a self-executable file. The default launch script used by Spring Boot prints a warning if run as root. This is mainly in place to prevent running Spring Boot jars as services under the root account. Since pbandk doesn't need the service-related functionality, we should probably replace the default Spring Boot launch script with a much-simplified custom version using something like:

tasks.getByName<BootJar>("bootJar") {
    launchScript {
        script = file("src/custom.script")
    }
}
@garyp garyp added the bug Something isn't working label Jul 28, 2020
@strophy
Copy link

strophy commented Jan 5, 2023

Hi, I'm trying to add the protoc-gen-kotlin plugin to https://github.com/rvolosatovs/docker-protobuf (maybe this would resolve #224 for you?) and I'm running into this problem with the warning from Spring Boot about running as root. I'm trying to determine if it would be easier to make this change away from Spring Boot in pbandk, or if we should figure out how to adjust the container running the file to use an unprivileged user. Thoughts?

@garyp garyp added the help wanted Extra attention is needed label Jan 5, 2023
@garyp
Copy link
Collaborator Author

garyp commented Jan 5, 2023

In general, using an unprivileged user is best practice for Docker containers. But I don't know if that would make the docker-protobuf container more difficult to use since it's main purpose is to read/write files outside of the container and doing that with non-root permissions could be more challenging.

I don't think the change on the pbandk side to make this work properly would be that difficult if you wanted to tackle it on the pbandk side. It involves:

  1. Updating the launchScript definition at https://github.com/streem/pbandk/blob/master/protoc-gen-pbandk/jvm/build.gradle.kts#L29 to use a custom script path (see my example above).
  2. Creating the custom script. I believe this is the script used by default: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-tools/spring-boot-loader-tools/src/main/resources/org/springframework/boot/loader/tools/launch.script. You could start simple and just remove the root user warning from that script. Or if you're feeling more ambitious, you could strip out the majority of what's in that script since we don't need any of the service-related init.d and systemd functionality in that script.

@strophy strophy linked a pull request Feb 2, 2023 that will close this issue
@strophy
Copy link

strophy commented Dec 12, 2024

I'm just using the script as an intermediate build stage for a separate final image, having this script available would be the easiest solution for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working component-codegen help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants