Personnellement je suis un peu sceptique vis-à-vis de sysbox, qui si je ne me trompe pas, repose surtout sur l'utilisation de user namespaces (comme rootless et podman). Le problème des user namespaces c'est que depuis des années on se rend compte que son code (privilégié de surcroît) est problématique et qu'autoriser son accès à des utilisateurs standards est généralement une mauvaise pratique. Et si je ne me trompe pas, avec sysbox, les appels systèmes sont toujours satisfaits par le kernel hôte.
En l'occurrence, Docker Desktop isole l'ensemble des conteneurs dans une VM, mais du coup je doute toujours de l'intérêt de sysbox par rapport à runc + usersn-remap si quelqu'un veut faire la même chose. Je pense que la meilleure approche à terme serait une solution similaire à ce que fait Google avec gVisor (qui fournit un runtime OCI-compliant), qui n'est pas sans défauts mais qui mérite le coup d'oeil.
[^] # Re: Intégration sysbox dans runC
Posté par Wonderfall (site web personnel) . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 3.
Personnellement je suis un peu sceptique vis-à-vis de sysbox, qui si je ne me trompe pas, repose surtout sur l'utilisation de user namespaces (comme rootless et podman). Le problème des user namespaces c'est que depuis des années on se rend compte que son code (privilégié de surcroît) est problématique et qu'autoriser son accès à des utilisateurs standards est généralement une mauvaise pratique. Et si je ne me trompe pas, avec sysbox, les appels systèmes sont toujours satisfaits par le kernel hôte.
En l'occurrence, Docker Desktop isole l'ensemble des conteneurs dans une VM, mais du coup je doute toujours de l'intérêt de sysbox par rapport à runc + usersn-remap si quelqu'un veut faire la même chose. Je pense que la meilleure approche à terme serait une solution similaire à ce que fait Google avec gVisor (qui fournit un runtime OCI-compliant), qui n'est pas sans défauts mais qui mérite le coup d'oeil.