New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[daemon] add local.privileged-mounts setting
#2150
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2150 +/- ##
==========================================
- Coverage 82.14% 82.08% -0.06%
==========================================
Files 184 185 +1
Lines 9536 9574 +38
==========================================
+ Hits 7833 7859 +26
- Misses 1703 1715 +12
Continue to review full report at Codecov.
|
cdc28d2
to
2a71bef
Compare
This way instances with mounts defined prior to disabling of the feature will report why there's no mounts on `info` and `start`.
024612f
to
fa85d30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks I have a few small things inline, but this looks good and works well overall (I have yet to try the counterpart though).
A couple points that I think are worth signaling:
- If primary is launched with mounts disabled, it doesn't get the Home mount, even if the setting is later enabled. I suppose this is as expected, and kind of consistent with what happens when changing the name of the primary instance to an instance that already existed (it keeps its mounts, or absence thereof).
- The security of this approach relies on the daemon settings not being writable (just deletable on Linux/Mac). If someone was able to edit
DAEMON_CONFIG_HOMEon Linux, change the permissions of certain Windows folders, or even change the name of the multipass daemon, they could have a chance at changing the setting. All of those should again require elevated privileges, but something we need to bear in mind in future changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* If primary is launched with mounts disabled, it doesn't get the Home mount, even if the setting is later enabled. I suppose this is as expected, and kind of consistent with what happens when changing the name of the primary instance to an instance that already existed (it keeps its mounts, or absence thereof).
Yeah, that's by design.
* The security of this approach relies on the daemon settings not being writable (just deletable on Linux/Mac). If someone was able to edit `DAEMON_CONFIG_HOME` on Linux, change the permissions of certain Windows folders, or even change the name of the multipass daemon, they could have a chance at changing the setting. All of those should again require elevated privileges, but something we need to bear in mind in future changes.
Yup, this relies on multipass set local.* requiring privileged operation. But it's not special in that we don't want any local.* settings being modifiable without privileges.
Co-authored-by: Ricardo Abreu <ricab@ricabhome.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks.
|
bors r+ |
|
Build failed: |
|
bors retry |
|
Build failed: |
[daemon] add `local.privileged-mounts` setting
Documentation updated at: https://multipass.run/docs/set-command?#local.privileged-mounts