Chmod created hostpath directories to 777 #1991
Conversation
k8s-ci-robot
added
size/XS
|
Can one of the admins verify this patch? |
|
I'm not entirely sure if the defer for setting the umask back is good enough, or if I should try to set it back more immediately in the two obvious paths it needs to be set back |
|
@minikube-bot ok to test |
Codecov Report
@@ Coverage Diff @@
## master #1991 +/- ##
==========================================
- Coverage 29.87% 29.85% -0.02%
==========================================
Files 77 77
Lines 4760 4763 +3
==========================================
Hits 1422 1422
- Misses 3158 3161 +3
Partials 180 180
Continue to review full report at Codecov.
|
|
Can someone help me understand what the test failures mean? Am unsure... |
|
@yuvipanda sorry was related to me working on some of the integration servers. @minikube-bot retest this please |
yuvipanda
changed the title
|
Updated to use chmod per suggestion from @dlorenc |
umask affects the entire process, while this is clearer
| @@ -73,6 +73,11 @@ func (p *hostPathProvisioner) Provision(options controller.VolumeOptions) (*v1.P | |||
| return nil, err | |||
| } | |||
|
|
|||
| // Explictly chmod created dir, so we know mode is set to 0777 regardless of umask | |||
| if err := os.Chmod(path, 0777); err != nil { | |||
|
Are these failures real? |
|
Should be ok. |
|
Thank you very much!!! |
|
Can I be a massive pain and ask if we can get a release with this in? It's causing me all sorts of headaches at the moment. Nightly is fine but I can't find a way that's current where I can access the build for this PR. |
|
We publish CI artifacts for each PR: To access this build (for Mac) the link would be: |
|
Thanks! I did see that - what threw me was I couldn't access 2025 for some reason so I assumed based on the directory index that these had stopped being published in February. I've downloaded that - it seems to fix directory permissions but I'm still seeing weird issues with files that have been written into said directories. Am I mad or is that a possibility? Seems to only be after they've been written by a user in the container who is not root, i.e. write a file as a non-root user, then try to write to it again and you get a permissions issue. I can replicate this with php -a and then file_put_contents to a file (first write is fine, subsequent one isn't). Using vim, I get read-only file but then with the option to overwrite with :w! Super confusing anyway :( |
Fixes #1990