fix(node): reject staging path mounted from unexpected source#152
Merged
Conversation
disperate
approved these changes
Jun 3, 2026
mweibel
force-pushed
the
node-request-logger
branch
from
01d8e88 to
9d1fbe5
Compare
Verify if stagingTargetPath is mounted and verify the mount source matches what we expect. This verification is done using LUKS paths or by resolving the symlink in the other case. To simplify the API surface, the code has been refactored to have a new GetMountInfo function which answers both former IsMounted and GetMountSources APIs.
mweibel
force-pushed
the
stage-source-verify
branch
from
3c0c3a8 to
c2adec9
Compare
mweibel
added a commit
that referenced
this pull request
Jun 18, 2026
The stale-mount check introduced in #152 compares mountInfo.Source (the string findmnt reads from /proc/self/mountinfo) against an expected path. For non-LUKS volumes the expected path was filepath.EvalSymlinks(source), where source is the by-id path returned by FinalizeVolumeAttachmentAndFindPath, e.g. `/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>`. Concretely, on restage of a non-LUKS volume we ended up comparing: expected = "/dev/sdb" (EvalSymlinks resolves the by-id symlink to the kernel device name) mountInfo.Source = "/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>" (findmnt prints the path that was passed to mount(2), not the resolved kernel name) Due to this difference, NodeStageVolume refused to acknowledge this as a legitimate mount. The LUKS branch was not affected. There, expected is "/dev/mapper/<volumeName>", which is also the string findmnt reports for that mount, so the compare matched. This change replaces the string compare with a kernel device-number compare for both branches. This is done by: 1. running Stat on the expected block device file and read st_rdev (the major:minor it represents) 2. running Stat on the staging path and read st_dev (the major:minor of the filesystem mounted there). Equal numbers mean the same underlying device regardless of which path string findmnt printed.
mweibel
added a commit
that referenced
this pull request
Jun 18, 2026
The stale-mount check introduced in #152 compares mountInfo.Source (the string findmnt reads from /proc/self/mountinfo) against an expected path. For non-LUKS volumes the expected path was filepath.EvalSymlinks(source), where source is the by-id path returned by FinalizeVolumeAttachmentAndFindPath, e.g. `/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>`. Concretely, on restage of a non-LUKS volume we ended up comparing: expected = "/dev/sdb" (EvalSymlinks resolves the by-id symlink to the kernel device name) mountInfo.Source = "/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>" (findmnt prints the path that was passed to mount(2), not the resolved kernel name) Due to this difference, NodeStageVolume refused to acknowledge this as a legitimate mount. The LUKS branch was not affected. There, expected is "/dev/mapper/<volumeName>", which is also the string findmnt reports for that mount, so the compare matched. This change replaces the string compare with a kernel device-number compare for both branches. This is done by: 1. running Stat on the expected block device file and read st_rdev (the major:minor it represents) 2. running Stat on the staging path and read st_dev (the major:minor of the filesystem mounted there). Note that step 2 no longer reads mountInfo.Source. Instead of asking findmnt what path mount(2) was called with,we run stat on stagingTargetPath directly. GetMountInfo is still used to detect whether anything is mounted there and to check propagation, just not for the equality decision. Equal numbers mean the same underlying device regardless of which path string findmnt printed.
3 tasks
mweibel
added a commit
that referenced
this pull request
Jun 22, 2026
The stale-mount check introduced in #152 compares mountInfo.Source (the string findmnt reads from /proc/self/mountinfo) against an expected path. For non-LUKS volumes the expected path was filepath.EvalSymlinks(source), where source is the by-id path returned by FinalizeVolumeAttachmentAndFindPath, e.g. `/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>`. Concretely, on restage of a non-LUKS volume we ended up comparing: expected = "/dev/sdb" (EvalSymlinks resolves the by-id symlink to the kernel device name) mountInfo.Source = "/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>" (findmnt prints the path that was passed to mount(2), not the resolved kernel name) Due to this difference, NodeStageVolume refused to acknowledge this as a legitimate mount. The LUKS branch was not affected. There, expected is "/dev/mapper/<volumeName>", which is also the string findmnt reports for that mount, so the compare matched. This change replaces the string compare with a kernel device-number compare for both branches. This is done by: 1. running Stat on the expected block device file and read st_rdev (the major:minor it represents) 2. running Stat on the staging path and read st_dev (the major:minor of the filesystem mounted there). Note that step 2 no longer reads mountInfo.Source. Instead of asking findmnt what path mount(2) was called with,we run stat on stagingTargetPath directly. GetMountInfo is still used to detect whether anything is mounted there and to check propagation, just not for the equality decision. Equal numbers mean the same underlying device regardless of which path string findmnt printed.
mweibel
added a commit
that referenced
this pull request
Jun 22, 2026
The stale-mount check introduced in #152 compares mountInfo.Source (the string findmnt reads from /proc/self/mountinfo) against an expected path. For non-LUKS volumes the expected path was filepath.EvalSymlinks(source), where source is the by-id path returned by FinalizeVolumeAttachmentAndFindPath, e.g. `/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>`. Concretely, on restage of a non-LUKS volume we ended up comparing: expected = "/dev/sdb" (EvalSymlinks resolves the by-id symlink to the kernel device name) mountInfo.Source = "/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_<serial>" (findmnt prints the path that was passed to mount(2), not the resolved kernel name) Due to this difference, NodeStageVolume refused to acknowledge this as a legitimate mount. The LUKS branch was not affected. There, expected is "/dev/mapper/<volumeName>", which is also the string findmnt reports for that mount, so the compare matched. This change replaces the string compare with a kernel device-number compare for both branches. This is done by: 1. running Stat on the expected block device file and read st_rdev (the major:minor it represents) 2. running Stat on the staging path and read st_dev (the major:minor of the filesystem mounted there). Note that step 2 no longer reads mountInfo.Source. Instead of asking findmnt what path mount(2) was called with,we run stat on stagingTargetPath directly. GetMountInfo is still used to detect whether anything is mounted there and to check propagation, just not for the equality decision. Equal numbers mean the same underlying device regardless of which path string findmnt printed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Verify if stagingTargetPath is mounted and verify the mount source matches what we expect.
This verification is done using LUKS paths or by resolving the symlink in the other case.
To simplify the API surface, the code has been refactored to have a new GetMountInfo function which answers both former IsMounted and GetMountSources APIs.