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

Wrong location for java.security used in Dockerfile.jvm and others #16471

Closed
flygarej opened this issue Apr 13, 2021 · 6 comments · Fixed by #16726
Closed

Wrong location for java.security used in Dockerfile.jvm and others #16471

flygarej opened this issue Apr 13, 2021 · 6 comments · Fixed by #16726

Comments

@flygarej
Copy link

When creating a project on quarkus.io, the Dockerfile for jvm and legacy-jar use Java 11 while assuming an old location of java.security.
In src/main/docker/Dockerfile.{jvm, legacy-jar}:

RUN microdnf install curl ca-certificates ${JAVA_PACKAGE}
&& microdnf update
&& microdnf clean all
&& mkdir /deployments
&& chown 1001 /deployments
&& chmod "g+rwX" /deployments
&& chown 1001:root /deployments
&& curl https://repo1.maven.org/maven2/io/fabric8/run-java-sh/${RUN_JAVA_VERSION}/run-java-sh-${RUN_JAVA_VERSION}-sh.sh -o /deployments/run-java.sh
&& chown 1001 /deployments/run-java.sh
&& chmod 540 /deployments/run-java.sh
&& echo "securerandom.source=file:/dev/urandom" >> /etc/alternatives/jre/lib/security/java.security

The the subpath lib/security was valid up to and including Java 8, and in later versions have been replaced with conf/security, so the line should read:

&& echo "securerandom.source=file:/dev/urandom" >> /etc/alternatives/jre/conf/security/java.security to ensure the right location is used.

Also: a heads up, OpenJDK introduces an overriding property file that is run after both the conf/security/java.security and the optional overriding one given by command line -Djava.security.properties= have been read.
See https://asamalik.fedorapeople.org/fedora-docs-antora/en_US/fedora/rawhide/release-notes/sysadmin/Security/ for details, as this is now default behaviour in the Docker image.

@quarkus-bot
Copy link

quarkus-bot bot commented Apr 13, 2021

/cc @sberyozkin

@maxandersen
Copy link
Contributor

@flygarej could you make a PR for the change ? i'm not sure I would do it proper justice :)

for details, as this is now default behaviour in the Docker image.

just to be clear - what image does "the Docker image" refer to here specifically ?

@flygarej
Copy link
Author

flygarej commented Apr 16, 2021

I'll give it a shot.
I tested using1.13.1.Final, and created a sample project.

In the src/main/docker/Docker.jvm there is an error, resulting i a build that does not match what was intended.

The image is created from registry.access.redhat.com/ubi8/ubi-minimal:8.3 to which is then added the ca-certificates and java-11-openjdk-headless, both latest versions which are then configured by the script.

The problem is the line

&& echo "securerandom.source=file:/dev/urandom" >> /etc/alternatives/jre/lib/security/java.security

The problem with this is that the location is not valid for Java > 8. Up to and including Java 8, the location of java.security was (with reasonable certainty) /etc/alternatives/jre/lib/security/java.security but after Java 8 it was changed to
/etc/alternatives/jre/conf/security/java.security

The above script will create a new java security file that only contains the line securerandom.source=file:/dev/urandom and it will not be read by the JVM. Change the line to
&& echo "securerandom.source=file:/dev/urandom" >> /etc/alternatives/jre/conf/security/java.security

and the configuration of the built image will match what was intended.

(It's also worth noting for those who tweak their java.security that OpenJDK introduces one more configuration file, in /etc/crypto-policies/back-ends/java.config that will be read after the /etc/alternatives/jre/conf/security/java.security and any java.security given on commandline overriding them with "safe" system-wide values. This new file is not part of the PR, really, but deserves mention as it tends to bite oldtimers (that'd be me) migrating to openJDK pretty bad.)

@gsmet
Copy link
Member

gsmet commented Apr 22, 2021

@flygarej I had a look at my local java.security file and I see the securerandom.source is already defined. Are we sure adding something at the bottom takes precedence?

gsmet added a commit to gsmet/quarkus that referenced this issue Apr 22, 2021
Fixes quarkusio#16471
The path has changed with Java 11.
@gsmet
Copy link
Member

gsmet commented Apr 22, 2021

I created #16726 to address this.

@flygarej
Copy link
Author

flygarej commented Apr 22, 2021

@flygarej I had a look at my local java.security file and I see the securerandom.source is already defined. Are we sure adding something at the bottom takes precedence?

Just tested, and I can confirm that the last line takes precedence.

@quarkus-bot quarkus-bot bot added this to the 2.0 - main milestone Apr 22, 2021
@gsmet gsmet modified the milestones: 2.0 - main, 1.13.3.Final Apr 26, 2021
gsmet added a commit to gsmet/quarkus that referenced this issue Apr 26, 2021
Fixes quarkusio#16471
The path has changed with Java 11.

(cherry picked from commit a07bd52)
gsmet added a commit to gsmet/quarkus that referenced this issue Apr 26, 2021
Fixes quarkusio#16471
The path has changed with Java 11.

(cherry picked from commit a07bd52)
@gsmet gsmet modified the milestones: 1.13.3.Final, 1.11.7.Final Apr 29, 2021
gsmet added a commit to gsmet/quarkus that referenced this issue Apr 29, 2021
Fixes quarkusio#16471
The path has changed with Java 11.

(cherry picked from commit a07bd52)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants