3cacf290bb
Implement this in two parts: 1. Permissions checks, getting a path from appropriate storage pool 2. Actual data import The first part is done by qubesd in a standard way, but then, instead of accepting all the data (which may be several GB), return a path to which a shell script (in practice: `dd` command) will write the data. Then the script call back to qubesd again to report success/failure and qubesd response from that call is actually returned to the user. This way we do not pass all the data through qubesd, but still can control the process from there in a meaningful way. Note that the last part (second call to qubesd) may perform all kind of verification (like a signature check on the data, or so) and can also prevent VM from starting (hooking also domain-pre-start event) from not verified image. QubesOS/qubes-issues#2622 |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| domain.py | ||
| file.py | ||
| kernels.py | ||
| lvm.py | ||
| README.md | ||
WNI File storage
Before v3.1 there existed a draft wni storage. You can find it in the git history
(it was in /core/storage directory, now gone)