Keep OpenVMM's report and console files readable under a restrictive umask
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 62/100
Research direction
Start with openvmm/openvmm/openvmm_entry/src/microvm/report.rs and openvmm/openvmm/openvmm_entry/src/serial_io.rs to trace how the report and captured console files are created. Compare the two listed options and check how #628 handles file modes; done means both files remain readable by their owner under a restrictive umask without unintentionally changing console permissions under the common umask 022.
Written by the indexing model from the issue text.
Description
Summary
An OpenVMM that nvx::host::process::launch spawns inherits the caller's umask. OpenVMM does not set the modes of the files it creates for the caller again, so under a umask that clears the owner's own read permission (for example 0400), the owner cannot read them:
- The microVM report (
openvmm/openvmm/openvmm_entry/src/microvm/report.rs) is staged in atempfilecreated with mode0600and published without achmod, so umask0400publishes it with mode0200. - A console captured to a file (
file_serialinopenvmm/openvmm/openvmm_entry/src/serial_io.rs) is opened withcreate(true)(mode0666), so umask0400leaves it at0266.
The sandbox store already sets the modes of its own files again (#628), so its records stay usable under such a umask; this issue covers only the files that OpenVMM writes.
Options
- In nvx-rs, set a fixed umask such as
0o077in the child's existingpre_exechook (nvx-rs/src/host/sys/process.rs,detach). This also changes a console file from0644to0600under the common umask022. - In OpenVMM, set the intended mode of the report and the console file explicitly after creating them.
Notes
A umask that clears the owner's own permissions is unusual. This was found in the final review of #628 and deferred there as out of scope.
- Dominant language
- Python
- Stars
- 408
- Forks
- 28
- Avg merge
- 15h 15m
- Merged PRs (30d)
- 322
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/nvx
-
bug-hunt confirmed good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
Similar issues
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
yunaremaia/proto-drift#22 ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
yunaremaia/memwatch#96 ·
-
bug good first issue
Difficulty 1/5 Under an hour Newbie friendliness 91/100
yunaremaia/ci-gate-watch#34 ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
yunaremaia/agent-capability-attestation#64 ·
Maintainers usually reply within 1 day
-
bug good first issue
Difficulty 1/5 Under an hour Newbie friendliness 86/100
yunaremaia/agent-call-graph#43 ·
Maintainers usually reply within 1 day