1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
//! ЄДИНЕ місце в крейті, де guest отримує (чи не отримує) права на диск —
//! §3.9: "читання — read-only preopen кореня репозиторію". Кожен із
//! чотирьох `Wasm*::call*` (`detector.rs`/`verify.rs`/`ast_facts.rs`/
//! `t0.rs`) будує `Store` для guest-виклику РІВНО через
//! [`read_only_repo_ctx`] — жодної іншої точки конструювання `WasiCtx` у
//! крейті немає, тож "мутуючий guest" не потребує домовленості чи ревʼю:
//! щоб він з'явився, хтось мусив би змінити ЦЮ функцію (видно в diff).
use Path;
use ;
/// Read-only `WasiCtx` з одним preopen — коренем репозиторію спроби,
/// змонтованим у guest-і як `/`.
///
/// `FsPerms::ReadOnly` — це ВЕСЬ бюджет прав, який [`WasiCtxBuilder`] тут
/// отримує; `FsPerms::ReadWrite` ніде в цій функції (і ніде більше в
/// крейті) не згадується.
///
/// До `wasmtime-wasi` 48 права були двома бітовими наборами
/// (`DirPerms::READ` + `FilePerms::READ`, і окремо існував
/// `DirPerms::MUTATE`); 48 звів їх до одного enum-а з двома варіантами.
/// Для цього крейта заміна СИЛЬНІША за попередній стан: раніше «нічого не
/// мутує» треба було вичитувати з комбінації двох наборів прапорців, тепер
/// це один літерал, який або `ReadOnly`, або ні — і третього стану, який
/// хтось міг би зібрати неуважною комбінацією бітів, більше не існує.
///
/// Наслідок незмінний: guest, що намагається
/// писати чи створювати/видаляти файл через `wasi:filesystem` (а саме цим
/// шляхом іде звичайний `std::fs::write` у скомпільованому для
/// `wasm32-wasip2` guest-і — доккоментар `detector.rs`, тест
/// `write_attempt_is_denied_by_the_read_only_preopen`), отримує помилку від
/// самого wasmtime-wasi ще до того, як його код побачив би файлову систему
/// — заборона за побудовою, не за угодою застосунку.
///
/// Хостовий `host-fs.read-file` (`crate::host_state`) — ДРУГИЙ, вужчий
/// шлях читання (доккоментар `wit/host.wit`), який іде НЕ через цей
/// `WasiCtx`, а напряму host-side `std::fs`; він так само ніколи не пише
/// (сигнатура `host-fs` не має жодної функції запису), тож обидва шляхи
/// читання, які §3.9 називає, лишаються read-only незалежно один від
/// одного.
pub