-
Notifications
You must be signed in to change notification settings - Fork 112
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
AppDir should be marked as readonly in export.go #1350
Comments
I could be wrong, but I think we are relying on the platform here to mount the workspace directory with the expected permissions. This came up awhile back when pack was doing something strange with workspace permissions. |
When i build an image with either pack or kpack i see that my working directory is set to be writable, i would have thought that this should not be the case? (I think it used to not be?) Would this still be the platforms responsibility? Not sure i am following |
Pack does set the write permission, see buildpacks/pack#1800 for discussion around this. @tomkennedy513 @chenbh do you have insight into how kpack handles workspace permissions? |
Wondering if we can make this configurable?
We have use cases where we do not want the application directory to be writable |
You could make an argument for pulling this into the lifecycle, but right now it is up to the platforms to manage. We should check how this is done in kpack and how easy it would be to change. |
I can't remember where we landed with this. I think @AidanDelaney was going to ask around about what is desired. |
Summary
I believe it used to be the case that the working directory got marked as read only (0755 at least) at export time. Currently
/workspace
is has mode 777 which i believe is not intentionalProposal
I believe we can mark the app directory to read only (or at least 755) here
lifecycle/phase/exporter.go
Line 163 in 44b7041
Related
RFC #___
Context
If this is reasonable I am happy to put up a PR to address this
The text was updated successfully, but these errors were encountered: