arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

Reword

Browse source
This commit is contained in:
Quentin 2024-02-07 12:03:34 +01:00
parent 352f692239
commit 20c08bbc46
Signed by untrusted user: quentin
GPG key ID: E9602264D639FF68
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
_posts/2024-02-06-fosdem.md
View file

@ -123,8 +123,8 @@ La rétro-compatibilité peut alors s'envisager avec des outils comme [gVisor](h
On pourrait alors imaginer un service de serverless/lambda function sur ce modèle. En gros le principe d'un système de ce genre, c'est de charger le code de l'utilisateur qu'en cas de besoin. C'est un peu la version cloud de [inetd](https://fr.wikipedia.org/wiki/Inetd) si vous préférez. Donc on aurait un daemon web qui écouterait. Lors de la réception d'une requête HTTP, il scannerait le champs Host de la requête et son URL. En fonction de cette dernière, il demanderait à l'orchestrateur de démarrer le service adéquat, et de connecter ses descripteurs de fichier pour gérer la requête/réponse. Là encore, si l'utilisateur veut que son service puisse accéder à des ressources autres, il devra les déclarer au moment de publier son code, et ne pourra pas outrepasser ce qui lui est permis. On pourrait alors imaginer un service de serverless/lambda function sur ce modèle. En gros le principe d'un système de ce genre, c'est de charger le code de l'utilisateur qu'en cas de besoin. C'est un peu la version cloud de [inetd](https://fr.wikipedia.org/wiki/Inetd) si vous préférez. Donc on aurait un daemon web qui écouterait. Lors de la réception d'une requête HTTP, il scannerait le champs Host de la requête et son URL. En fonction de cette dernière, il demanderait à l'orchestrateur de démarrer le service adéquat, et de connecter ses descripteurs de fichier pour gérer la requête/réponse. Là encore, si l'utilisateur veut que son service puisse accéder à des ressources autres, il devra les déclarer au moment de publier son code, et ne pourra pas outrepasser ce qui lui est permis.
Bref, on aurait un système avec une approche robuste de l'isolation, construit sur des briques qui ont fait leurs preuves, des possibilités d'observations et de debugs importantes, qui reste flexible : il serait construit sur des streams, un modèle de sécurité reconnu, et la capacité d'offrir des APIs de (très) haut niveau. Cette idée est partiellement discutée dans un papier intitulé [A capability inspired low level security model based on modern Linux kernels](http://arkanis.de/projects/2013-01%20Capabilities/A%20capability%20inspired%20low%20level%20security%20model%20based%20on%20modern%20Linux%20kernels.pdf). Ma proposition se différencie dans le sens où, pour contourner certaines limitations des descripteurs de fichier, j'envisage des daemons en espace utilisateur qui se chargeraient de réduire le scope.
## Conclusion ## Conclusion
J'ai vu deux trois autres choses au FOSDEM. En vrac : j'ai bien aimé [la présentation de Garage](https://fosdem.org/2024/schedule/event/fosdem-2024-3009-advances-in-garage-the-low-tech-storage-platform-for-geo-distributed-clusters/) par Alex, j'ai beaucoup apprécié aussi le lightning talk de Emily Omier [Project websites that don't suck](https://fosdem.org/2024/schedule/event/fosdem-2024-3154-project-websites-that-don-t-suck/) : très pertinent, très bien exécuté. Beaucoup de monde, pas eu le temps de faire la bamboche, il est temps d'aller me reposer. J'ai vu deux trois autres choses au FOSDEM. En vrac : j'ai bien aimé [la présentation de Garage](https://fosdem.org/2024/schedule/event/fosdem-2024-3009-advances-in-garage-the-low-tech-storage-platform-for-geo-distributed-clusters/) par Alex, j'ai beaucoup apprécié aussi le lightning talk de Emily Omier [Project websites that don't suck](https://fosdem.org/2024/schedule/event/fosdem-2024-3154-project-websites-that-don-t-suck/) : très pertinent, très bien exécuté.