Multi-plateforme plat Décidé
Un seul moteur Rust, cinq carrosseries : binaires statiques musl cross-compilés, quatre écosystèmes de signature traités comme infrastructure de release, et une stratégie Synology assumée — non-root par dépôt tiers comme chemin nominal.
Décision 1 — Un binaire statique par cible
Cross-compilation Rust vers x86_64- et aarch64-unknown-linux-musl (outil cross) → binaires statiques, zéro dépendance glibc, mêmes fonctionnalités partout. Un seul codebase, pas de version « NAS » au rabais.
Décision 2 — La matrice de cibles v1
| Plateforme | Format | Service | Signature |
|---|---|---|---|
| Linux | binaire statique + deb/rpm | systemd | checksums / sigstore |
| Windows x86_64 | MSI | Service Windows (SYSTEM) | Authenticode EV — sinon SmartScreen effraie les clients |
| macOS | PKG, binaire universel arm64+x86_64 | launchd daemon | Developer ID + notarisation (obligatoire depuis 10.15) |
| Synology | SPK (métadonnées DSM 7) | init DSM, non-root | dépôt tiers — voir décision 3 |
| QNAP | QPKG (QDK) | init QTS | signature QPKG (self-signed possible) |
Architectures : x86_64 + aarch64 en v1 (couvre les NAS récents) ; armv7 (vieux modèles d’entrée de gamme) en best-effort plus tard.
Décision 3 — Synology : non-root par dépôt tiers, chemin nominal
Depuis DSM 7, un paquet ne peut tourner root que signé par Synology. Après analyse, ce n’est pas un problème — le chemin nominal est ailleurs :
- Distribution par dépôt tiers — mécanisme officiel de DSM : l'utilisateur ajoute la source de paquets dans le Centre de paquets, le paquet apparaît dans l'onglet « Communauté » (DSM 7 affiche un avertissement « éditeur tiers » ; DSM 6 demande en plus de régler le niveau de confiance). Chemin éprouvé commercialement par des produits de backup existants : zéro gatekeeper, contrôle total du rythme de release.
- Le non-root suffit pour le cas d'usage NAS. Le paquet reçoit l'accès aux dossiers partagés à sauvegarder — et qui peut lire un fichier peut lire ses xattrs : les SynoACL sont capturées sans root (vérifié empiriquement). Les snapshots btrfs ? Peu pertinents ici : un NAS est un serveur de fichiers, pas un serveur Exchange — l'échelle stat/re-stat couvre le fichier occasionnellement modifié, et les applis hébergées (Docker, bases) relèvent des hooks pre/post.
- Ce qui reste réellement root-only — fichiers système DSM, xattrs
trusted.*, création de snapshots — est marginal, et la règle « rapporter, jamais mentir » l'affiche proprement. - Signature / partenariat Synology : reclassé « seulement si un vrai besoin root émerge un jour ». Rien à engager maintenant.
- Hors fondation : les contournements root (tâche planifiée, script sudo) — acceptables en dépannage documenté, jamais comme socle d'un produit : Synology peut fermer la porte à la prochaine mise à jour DSM.
Décision 4 — Les signatures comme infrastructure de release
À traiter comme un composant du pipeline de release (section L) : certificats gérés comme des secrets d’infrastructure, notarisation (notarytool + stapler) et signatures automatisées en CI.
Décision 5 — Les privilèges par plateforme, consolidés
Tous les renvois accumulés (snapshots, xattrs) atterrissent ici :
| Plateforme | L’agent tourne en | Ce que ça permet | Ce qui manque sinon |
|---|---|---|---|
| Linux serveur | root | snapshots LVM/btrfs/ZFS, trusted.*, tout le FS | — |
| Windows | SYSTEM | VSS, tous les fichiers, SACL | sans SYSTEM : pas de VSS ni fichiers verrouillés |
| macOS | root + Full Disk Access (TCC) | tout le FS — sans FDA, macOS cache Mail, Photos… même à root | FDA à accorder (déployable par MDM) |
| Synology | utilisateur de paquet (nominal) | partages accordés + leurs SynoACL/xattrs | fichiers système, trusted.*, snapshots — rapportés |
| QNAP | selon QPKG (root possible) | équivalent Linux si root | — |
Périmètre
Les spécificités sémantiques des systèmes de fichiers — sensibilité à la casse, normalisation Unicode NFC/NFD, MAX_PATH Windows, noms réservés — restent au sujet dédié de la section O : cette page traite du packaging et du runtime, pas des chemins.