fix: propagate read-only mount from staging path and volume capability in NodePublishVolume#1067
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andyzhangx The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
d2f9c15 to
3693475
Compare
There was a problem hiding this comment.
Pull request overview
Fixes a bug where NodePublishVolume could create a writable bind mount even when the underlying PV/staging mount and/or volume capability indicates the volume should be read-only.
Changes:
- Derive effective
readOnlyfromreq.Readonly, volume capability access mode, and staging mount options. - Propagate
roto the bind mount options when any read-only signal is present.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…y in NodePublishVolume Previously, NodePublishVolume only checked req.GetReadonly() to decide whether to add 'ro' to the bind mount options. This meant that when a PV had csi.readOnly: true or mountOptions including 'ro', but the pod spec volumeMounts did not explicitly set readOnly: true, the bind mount would be writable. Fix by also checking: 1. Volume capability access mode (MULTI_NODE_READER_ONLY, SINGLE_NODE_READER_ONLY) 2. Whether the staging mount path has 'ro' in its mount options This ensures read-only intent from PV-level settings is properly propagated to the final bind mount. Ref 987
3693475 to
44f583e
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
/retest |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Guard against nil volCap.GetMount() to prevent panic with block access type - Add volumeID and target to 'ro' mount flags log message for debuggability - Add unit tests for MULTI_NODE_READER_ONLY and SINGLE_NODE_READER_ONLY access modes - Add unit test for mount flags 'ro' propagation to bind mount - Add unit test for nil Mount (block access type) to verify no panic
|
Addressed review comments in daab8f2: Code fixes:
New unit tests:
Re: outdated comments about staging mount path normalization and double mount list scan — those were addressed in the previous revision that removed the staging mount path inspection. |
|
/retest |
|
/cherrypick release-4.13 |
|
@andyzhangx: cannot checkout DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
What type of PR is this?
/kind bug
What this PR does / why we need it:
When a PV has
csi.readOnly: trueor mount options includingro, but the pod specvolumeMountsdoes not explicitly setreadOnly: true, the bind mount inNodePublishVolumewas created withoutro, allowing writes to the supposedly read-only volume.How does it work:
NodePublishVolumenow checks three sources for read-only intent:req.GetReadonly()(existing — from pod specvolumeMounts.readOnly)MULTI_NODE_READER_ONLY,SINGLE_NODE_READER_ONLY)roin its mount options (propagated from PVmountOptionsorcsi.readOnly)If any of these indicate read-only, the bind mount gets
ro.Which issue(s) this PR fixes:
Ref #987
Does this PR introduce a user-facing change?