Closed lucming closed 2 weeks ago
linux-foundation-easycla[bot]
commented
2 weeks ago 
The committers listed above are authorized under a signed CLA.
k8s-ci-robot
commented
2 weeks ago [APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign leakingtapan for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
k8s-ci-robot
commented
2 weeks ago Welcome @lucming!
It looks like this is your first PR to kubernetes-sigs/aws-ebs-csi-driver 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.
You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.
You can also check if kubernetes-sigs/aws-ebs-csi-driver has its own contribution guidelines.
You may want to refer to our testing guide if you run into trouble with your tests not passing.
If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!
Thank you, and welcome to Kubernetes. :smiley:
k8s-ci-robot
commented
2 weeks ago Hi @lucming. Thanks for your PR.
I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
ConnorJC3
commented
2 weeks ago /close
Hi @lucming - unfortunately we will be unable to accept this PR. Creating mount directories with a permission set of 755 is an intentional security feature. Creating the directory with a permission of 777 would potentially allow any user on the host to control or modify the container's volume under the right conditions, as 777 grants all users write permissions.
If you need assistance with deploying the EBS CSI Driver (or would like to request a feature for your usecase), you can ask for support by creating an issue on this GitHub repository.
k8s-ci-robot
commented
2 weeks ago @ConnorJC3: Closed this PR.
lucming
commented
1 week ago /close
Hi @lucming - unfortunately we will be unable to accept this PR. Creating mount directories with a permission set of
755is an intentional security feature. Creating the directory with a permission of777would potentially allow any user on the host to control or modify the container's volume under the right conditions, as777grants all users write permissions.If you need assistance with deploying the EBS CSI Driver (or would like to request a feature for your usecase), you can ask for support by creating an issue on this GitHub repository.
Does lvm not need to consider this issue? @ConnorJC3
Is this a bug fix or adding new feature? bugfix
What is this PR about? / Why do we need it? The storage plugin used by the application is changed from lvm to ebs, and an error is reported that there is no write permission. logs as below:
We found out that the mount point for the lvm plugin on the host machine had 777 permissions, code: https://github.com/metal-stack/csi-driver-lvm/blob/master/pkg/lvm/lvm.go#L214 , while the ebs plugin's mount point had 755 permissions. After manually executing chmod 777, the service running normally.
What testing is done?