-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Remote Development Mode docker permissions #41029
Remote Development Mode docker permissions #41029
Conversation
This comment has been minimized.
This comment has been minimized.
🙈 The PR is closed and the preview is expired. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR!
I added a question that I want us to sort out before merging. Feel free to push back if I'm confused :).
# Remote Development Mode | ||
ENV QUARKUS_LAUNCH_DEVMODE=true | ||
RUN chmod o+rw -R /deployments | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really something we want to include in the default Dockerfile?
I could be convinced to provide a specific remote dev mode Dockerfile if it has value but the default one should be as generic as possible and allowing the app to write in /deployment
is not something we want if not in remote dev mode.
One option could be to comment it out but given they are very different use cases and you might need to use remote dev mode and then to build a container and it could be dangerous if you forgot to adjust it before building the prod container.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allowing the app to write in /deployment is not something we want if not in remote dev mode.
of course. I am glad you picked it up. and that would be a security risk. I meant to leave those 2 lines commented out, as options.
it could be dangerous if you forgot to adjust it before building the prod container.
regarding the second point, yes there is a risk that you would forget those in your real application. the only thing protecting us from that would be to have a separate dockerfile. but that seemed overkill to me. I guess we could add a precision in the comment (do not leave uncommented when building the prod container), and leave the responsibilty to the user. another more sophisticated way that we do not promote by default is generating the dockerfile based on properties you pick up from your pom, and/or a specific profile -Premote-dev
. that way you could make sure that this section is only added when you explicitly add the specific profile.
also initially I only added the doc clarification. may be that is sufficient (and less risky).
finally I was not sure I needed to update extensions/container-image/container-image-docker-common/deployment/src/test/resources/ubi* files
. I did it for consistency.
so what do you think?
- doc only?
- doc+qute template?
- doc+qute template+ubi test files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah so for me either we do doc only or we provide a separate Dockerfile. I'm not against the latter if you think it has value. Especially since if you are using remote dev, there's a good chance you will want two separate ones for the reason below.
we could add a precision in the comment (do not leave uncommented when building the prod container)
This is too dangerous. When you have to add this sort of comment, you can be sure it will go wrong for someone somewhere :).
Or even get pushed to Git because you were working on a large patch and it went unnoticed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think doc only is sufficient. I will make the change. thanks for the feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have also added For security reasons, this option should not be added to the production docker file.
in the doc.
and reverted the other changes.
5d3a952
to
2a47b97
Compare
This comment has been minimized.
This comment has been minimized.
Status for workflow
|
2a47b97
to
8831f06
Compare
This comment has been minimized.
This comment has been minimized.
8831f06
to
5224f69
Compare
Status for workflow
|
Fixes #40502