osutil: add mount/libmount package with option validator #14814
Merged
Conversation
This file contains 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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #14814 +/- ##
==========================================
+ Coverage 78.20% 78.26% +0.05%
==========================================
Files 1151 1152 +1
Lines 151396 152065 +669
==========================================
+ Hits 118402 119015 +613
- Misses 25662 25693 +31
- Partials 7332 7357 +25
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
zyga
force-pushed
the
fix/mount-control-option-validation-SNAPDENG-32984
branch
5 times, most recently
from
a45e563 to
f5aaf1d
Compare
We need to recognize and validate libmount-style mount options, such as those that one can use with the mount(1) utility on command line for possible conflicts. This is so that the apparmor parser, which does similar validation, does not fail "late" in the interface setup process, when given incorrect data by the mount-control interface. Note that the Darwin implementation of the function is a stub. Jira: https://warthogs.atlassian.net/browse/SNAPDENG-32984 Signed-off-by: Zygmunt Krynicki <[email protected]>
Mount APIs use event propagation terminology with the words mater and slave that are hard to change. Add the two files to the exception list. Signed-off-by: Zygmunt Krynicki <[email protected]>
Signed-off-by: Zygmunt Krynicki <[email protected]>
The mount-control interface used to allow requesting contradicting mount options, such as nodev and dev and would silently pass this down to apparmor_parser. The parser would detect this and cause the failure of the security setup. With this code we now detect this much earlier, at interface validation stage. Fixes: https://warthogs.atlassian.net/browse/SNAPDENG-32984 Signed-off-by: Zygmunt Krynicki <[email protected]>
zyga
force-pushed
the
fix/mount-control-option-validation-SNAPDENG-32984
branch
from
f5aaf1d to
c789f68
Compare
|
I've made the code compatible with Go 1.18 |
Meulengracht
approved these changes
Dec 11, 2024
|
|
||
| // ValidateMountOptions is a stub. | ||
| func ValidateMountOptions(opts ...string) error { | ||
| // This is not implemented for Darwin. We could implement it by baking all |
There was a problem hiding this comment.
Until the need arrives for this to be on darwin I think this is fine. I'd rather move things around when we need to than try to predict.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We need to recognize and validate libmount-style mount options, such as those that one can use with the mount(1) utility on command line for possible conflicts. This is so that the apparmor parser, which does similar validation, does not fail "late" in the interface setup process, when given incorrect data by the mount-control interface.
This patch adds the skeleton of the validator, along with read-only and read-write mount options.
Jira: https://warthogs.atlassian.net/browse/SNAPDENG-32984
NOTE: this is a draft, I need to hook it up to interfaces logic as well.
I have considered asking apparmor for this information but given that we cannot even discover the full set of known mount options and the interrogation is inefficient (compile and see if it gets ignored), I chose to just bake in the table. There are only 32 bits possible so we are not up an unbound problem anyway.
I've only added one pair of conflicting options as this is a draft solicitng review