Subuser est une sur‐couche à Docker, il permet de lancer des logiciels dans des conteneurs, avec un système simple de gestion des permissions, et un accès au serveur X. Subuser transforme les conteneurs Docker en programmes GNU/Linux normaux.
La suite de cette dépêche présente ce logiciel ainsi que la philosophie autour.
Merci à BAud, palm123 et eggman pour leur contributions/relectures
Sommaire
À propos…
Subuser permet de transformer un conteneur Docker en un programme normal, mais sans lui donner tous les privilèges, ainsi, par exemple, il ne peut accéder qu’au répertoire d’où il est appelé et non le /home complet de l’utilisateur.
Chaque subuser se voit attribuer un jeu de permissions, de façon similaire à Android, voici un exemple de fichier permissions.json (tiré de la documentation) :
{
"description" : "A web browser."
,"maintainer" : "Timothy Hobbs <timothyhobbs (at) seznam dot cz>"
,"executable" : "/usr/bin/firefox"
,"user-dirs" : ["Downloads"]
,"gui" : {"clipboard":true,"cursors":true}
,"sound-card" : true
,"allow-network-access" : true
}On sort ainsi du schéma « toutes les permissions ou rien » qui est la règle sur Android.
Subuser utilise la même syntaxe que les Dockerfile de Docker, ainsi il n’est pas nécessaire d’en apprendre une nouvelle.
L’accès au serveur X est sécurisé grâce à l’utilisation d’un pont X11 « Xpra », cf. les explications (en anglais).
L’architecture est distribuée, il est facile à n’importe qui d’ajouter son propre dépôt, la commande subuser pkg permet de maintenir les dépôts.
Utilisation de Git pour l’historique (le « registre ») : il est possible de facilement revenir en arrière si une mise à jour ne vous plaît pas, ou de bloquer les mises à jour si vous voulez rester sur une version précise. La commande subuser registry log permet de savoir ce qui a été installé ou mis à jour.
Philosophie
N. D. R. : j’ai eu l’occasion de rencontrer et discuter avec l’auteur de Subuser, c’est une personne très intéressante et qui a une vraie réflexion éthique et politique autour de son projet
Subuser est construit autour d’une réflexion politique et technique. Pour situer un peu l’auteur, on peut lire ce texte (en anglais) qui décrit ce qu’il appelle les « logiciels égalitaires ».
Dans les réflexions autour de Subuser, outre les aspects sécuritaires évidents, il y a une volonté de pouvoir utiliser un logiciel dans une version précise indéfiniment.
En effet, qui n’a jamais pesté après avoir vu une fonctionnalité disparaître ou une interface changer suite à une mise à jour sur un logiciel auquel il était habitué et qui le satisfaisait parfaitement ? Ou encore, après avoir vu un logiciel ne plus fonctionner à cause d’une mise à jour ou d’un changement du système d’exploitation ?
Subuser en comparaison avec xdg-app
N. D. R. : Subuser peut se comparer à xdg-app, aussi j’ai posé la question à l’auteur pour savoir ce qu’il en pensait, voici sa réponse (traduction en français plus bas) :
Xdg-app and subuser are very similar.
Subuser is about 9 months older than xdg-app and Alex Larson knew about
subuser when he wrote xdg-app. When I talked to him about his reason for
not just using subuser, he explained to me that he did not think that
Docker was a good candidate for packaging desktop applications. Xdg-app
has one big advantage in it's current state over subuser/Docker. It uses
OSTree, which allows for seamless data deduplication across images.
That's a really nice feature as it saves a lot of diskspace and makes
downloading images a lot faster.N.D.R. : cette fonctionnalité est envisagée également dans Subuser, cf. le paragraphe « Futur »
There are other philosophical differences as well. Subuser images are
meant to last forever and be portable, therefore, they are monolithic.
Xdg-app doesn't have the goal of either perfect portabilty or
everlasting images. Instead, xdg-app works more like traditional linux
software distribution. You can create an image for xdg-app and that
image relies on libraries such as the "gnome-runtime" those libraries
can be updated independently of the image. Subuser doesn't allow such a
feature because there is no way of guaranteeing that a new library will
be compatible with an old image.The next difference is that of portability. Xdg-app is very interested
in making sure that xdg-apps integrate well with gnome. They are
planning features to connect up dbus services which will allow xdg-apps
to, for example, access your gnome contacts list or your gnome
calendar. Subuser values portablilty and security over gnome
integration and so the subuser user experience may suffer as a result.
There is another face to this same issue. Xdg-app is trying to define
new dbus interfaces to allow xdg-apps to communicate with the outside
world. This means, that if you want your xdg-app to access the file
system, it will have to implement a new dbus file access API. Subuser
tries very hard to avoid such new interfaces and preferes to try to
emulate existing POSIX/LINUX protocols and APIs.Yet another difference is that subuser allows you to have multiple
subusers for a single image. This is usefull for web browsing. For
example, I can have a subuser for internet banking and another subuser
for typical web browsing and a third subuser for using google services
ect. And all of these subusers can share the same firefox/iceweasel
image. This allows for finer grained security policy than is possible
with xdg-app.
Traduction :
Xdg-app et Subuser sont très similaires.
Subuser est environ 9 mois plus vieux que Xdg-app et Alex Larson le connaissait quand il a écrit Xdg-app. Quand je lui ai demandé les raisons pour ne pas utiliser Subuser, il m’a expliqué qu’il ne pense pas que Docker soit un bon candidat pour empaqueter des applications de bureau.
Xdg‐app a pour le moment un gros avantage par rapport à Subuser/Docker : il utilise OSTree, qui permet une dé‐duplication des données homogène à travers les images. C’est une fonctionnalité vraiment chouette : ça économise beaucoup d’espace disque et permet un téléchargement des images beaucoup plus rapide.
N. D. R. : cette fonctionnalité est envisagée également dans Subuser, cf. le paragraphe Futur
Il y a d’autres différences philosophiques. Les images Subuser sont pensées pour fonctionner éternellement et être portables et, par conséquence, sont monolithiques.
Xdg-app n’a pour but ni une portabilité parfaite ni des images éternelles. Au contraire, Xdg-app fonctionne plus comme un système de distribution de logiciels Linux traditionnel. Vous pouvez créer une image pour Xdg-app, et cette image va se baser sur des bibliothèques comme le « gnome-runtime », bibliothèques qui peuvent être mises à jour indépendamment de l’image. Subuser ne permet pas ce type de fonctionnalité parce qu’il n’y a aucun moyen de garantir qu’une nouvelle bibliothèque sera compatible avec une ancienne image.Le point de divergence suivant est la portabilité. Xdg-app cherche vraiment à être sûr que les applications Xdg-app s’intègrent bien avec GNOME. Ils prévoient des fonctionnalités pour connecter un service D-Bus qui va permettre aux applications Xdg-app de, par exemple, accéder à la liste de contacts de GNOME ou à votre calendrier GNOME. Subuser préfère la portabilité et la sécurité à l’intégration à GNOME, aussi l’« expérience utilisateur » des utilisateurs de Subuser peut être moins bonne à cause de cela.
Il y a une autre facette à ce problème : Xdg-app veut définir de nouvelles interfaces D-Bus pour permettre aux applications Xdg-app de communiquer avec le monde extérieur. Ceci signifie, que si vous voulez que votre application Xdg-app accède au système de fichiers, elle devra implémenter une nouvelle API pour accéder aux fichiers via D-Bus. Subuser essaie autant que possible d’éviter ce type de nouvelle interface, et préfère émuler le protocole et les API POSIX/Linux existantes.Un autre point de divergence est que Subuser permet d’avoir plusieurs « subusers » (N. D. T. : sous‐utilisateurs) pour une même image. C’est pratique pour naviguer sur le Web. Par exemple, j’ai un subuser pour mes comptes sur Internet, un autre pour la navigation Web traditionnelle et un troisième pour utiliser les services de Google, etc. Et tous ces « subusers » peuvent partager la même image Firefox/Iceweasel (N. D. T. : et bientôt Firefox/
Iceweasel). Ceci permet une politique de sécurité plus fine qu’il n’est possible avec Xdg-app.
Il faut bien noter une conséquence majeure de ce que l’auteur explique avec D-Bus : xdg-app demande une modification des logiciels qui doivent appeler des fonctions spécifiques, tandis que Subuser permet d’utiliser un logiciel sans modification.
Futur
Le projet est déjà fonctionnel et tout à fait utilisable. L’auteur aimerait utiliser OSTree ou un mécanisme de dé‐duplication similaire dans les prochaines versions.
Il est également envisagé de remplacer Docker par une autre solution, ainsi que l’indique l’auteur suite à une question sur les permissions dynamiques (qui permettraient par exemple l’accès à un répertoire en fonction d’un argument du logiciel et non uniquement au répertoire courant ou spécifié dans la configuration) :
The plan is to move away from Docker and use runC directly. That will fix that problem, and then we will be able to have things like file dialogs which automatically grant permission to access a file…
Traduction :
L’idée est de quitter Docker et utiliser runC directement. Cela règlera le problème, et alors il sera possible d’avoir des choses comme une boîte de dialogue qui accorde automatiquement des autorisations d’accès à un fichier…
Comment aider ?
L’auteur aimerait beaucoup voir Subuser être empaqueté dans les distributions GNU/Linux, aussi si un développeur Debian, par exemple, lit cette dépêche et souhaite aider le projet, ce serait une contribution précieuse (c’est valable également pour les autres distributions, bien entendu).
Aller plus loin
- Site officiel (957 clics)
- what is subuser? (187 clics)
- Tutoriel rapide (338 clics)
# Xpra
Posté par Tangi Colin . Évalué à 1.
Je connaissais pas Xpra, si je comprend bien chaque conteneur à son serveur X à l'intérieur et Xpra sert de "proxy", j'ai bon ou je suis complètement à coté de la plaque ?
C'est pas un peu lourd par rapport a binder la socket X au lancement d'un conteneur ?
[^] # Re: Xpra
Posté par KiKouN . Évalué à 5.
Xpra est un peu plus qu'un simple proxy. Il permet déjà de garder une connexion X persistant pour le progamme. Ensuite, côté client X, on peut venir s'y connecter à volonté. On peut donc par exemple :
- Ouvrir Firefox sur un serveur sous Xpra.
- Venir s'y connecter avec un premier client et naviguer un peu.
- Venir s'y connecter avec un autre client et naviguer un peu.
Pour comparer avec la console, c'est une sorte de screen des applications X.
Dans le cas de subuser, on pourrais imaginer ces cas de figure :
- On pourrai endormir le conteneur pour le réutiliser plus tard sans perdre la session.
- On pourrai migrer le conteneur sur son portable par exemple sans perdre la session.
[^] # Re: Xpra
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Comme je l'ai compris, les conteneurs avec les applications ont juste une socket et le serveur Xpra est dans un conteneur à part (le client est lui dans un autre conteneur).
À l'usage, j'ai vu un Firefox tourner et on peut difficilement dire qu'il est dans un conteneur, c'est très fluide. Sur la page d'explications l'auteur indique que même pour les vidéos plein écran ça marche bien.
Le système est pensé pour pouvoir changer de serveur facilement, aussi quand Wayland sera dispo, il devrait être facile de faire la transition.
[^] # Re: Xpra
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
En relisant ton commentaire je me dis qu'il faut préciser que c'est fait pour des raisons de sécurité, un serveur X permet aux applications d'accéder aux autres, mettre Xpra au milieu permet de les isoler.
# Appimage
Posté par ZeroHeure (site web personnel) . Évalué à 5. Dernière modification le 26 février 2016 à 10:25.
Avec des objectifs un peu différents, autrefois il y avait Klik, venu de KDE. On a maintenant AppImage, lequel ressemble assez à l'empaquetage de binaires sous MacOSX. Ce projet n'ambitionne pas d'apporter la solution ultime! Car comme le dit son auteur :
En plus de Subuser et Xdg-App il y a aussi le projet de Lennart Poettering.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Application Windows ?
Posté par freejeff . Évalué à 4. Dernière modification le 26 février 2016 à 10:32.
Est il possible avec cet outil (ou d'autres) d'être en mesure de distribuer un ensemble de binaires statiques fait dans un conteneur Docker et de le déployer sous windows ? Je veux dire par là avoir accès aux répertoires du système hôte comme ce qui est proposé ici !
Cela permettrait de distribuer simplement un code linux sous windows sans se soucier de la portabilité !!
[^] # Re: Application Windows ?
Posté par damaki . Évalué à 5.
Docker sous Windows, ça n'est pas encore la fête pour le moment. Ça se contente de lancer une vm Linux headless sous VirtualBox et d'instancier les containers docker dedans. Mais ça viendra d'ici peu ; Microsoft collabore pas mal avec les gens de Docker pour faire aussi des containers Windows légers.
# Correction
Posté par Mimoza . Évalué à 2.
Vers la fin de la première traduction :
Sinon l'idée est vraiment bonne, et très intéressante pour des bureaux mobiles (ie : pas de machine fixe)
[^] # Re: Correction
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
salut,
je dois pas être réveillé, je ne vois pas de différence, où est la faute ? Iceweasel est barré dans la N.D.T. en référence à ce journal.
[^] # Re: Correction
Posté par Mimoza . Évalué à 2.
Heuu et bien non justement Iceweacel n'est pas barré dans le NDT chez moi, c'est pour cela que ça me semblait bizarre … (style nightgrey)
[^] # Re: Correction
Posté par xcomcmdr . Évalué à 6.
j'ai le thème par défaut de linuxfr, et c'est bien barré.
C'est donc ton CSS qui est mal barré. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Packaging deb/rpm
Posté par shann . Évalué à 1.
Hello,
Ce projet me semble prometteur et fort intéressant, connaissant le packaging pour Debian et CentOS/Red Hat, je serait ravis de contribuer au projet sur ce point.
[^] # Re: Packaging deb/rpm
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
salut sham, super !
Si tu veux tu peux me contacter sur goffi @ goffi . org (ou via XMPP, mon jid est renseigné ici, il y a juste à cliquer), ou directement Timothy, l'auteur (son adresse est dans l'exemple de configuration dans la dépêche).
Merci :)
[^] # Re: Packaging deb/rpm
Posté par Frédéric Blanc . Évalué à 1.
Réflexion non aboutie (je ne maitrise si Subuser, ni Docker) : Subuser utilisant Docker, ne serait-il pas «tout» simple de le distribuer… comme une image Docker ?
[^] # Re: Packaging deb/rpm
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Un des intérêts majeurs, c'est que tu donnes accès à ton environnement extérieur, par exemple le serveur X ou le système de fichier via un système simple de permissions. Tu peux toujours mettre dans un Docker, mais tu devras soit rester dans ton conteneur, soit avoir un moyen de donner ces permission (et donc refaire Subuser en gros).
En plus je ne suis pas sûr que faire tourner un Docker dans un conteneur Docker soit une super idée, notamment avec le système de fichiers par couches.
Je ne sais pas si je suis clair, mais la réponse est non, ça ne serait pas viable de distribuer ça via une image Docker.
[^] # Re: Packaging deb/rpm
Posté par Frédéric Blanc . Évalué à 1.
Si, très clair, preuve que j'ai pas encore bien cerné Docker et Subuser ;-)
# En France on utilise Marcel!
Posté par batousky . Évalué à 4.
Juste pour le fun, marcel, qui nous proposes des alias francisés pour les commandes docker.
# Une sur-couche à Docker. Parce que docker est mal pensé.
Posté par remyd1 . Évalué à 5.
Docker étant le standard de facto pour la gestion/utilisation des containers, il a fallu coder des sur-couches parce que Docker est mal pensé pour certains aspects. Je m'explique, la sécurité est l'un des grands points faibles de docker (daemon qui tourne en root, images non certifiées plein de trous de sécurité, etc…). Du coup, on se retrouve avec des couches et des sur-couches… Pourquoi ne pas prendre la bonne techno directement : rkt
Par ailleurs, il existe aussi des technos pour lesquelles on n'utilise pas de containers et qui permettent presque la même chose que des containers, cf : singularity
Sans parler de projets qui peuvent parfois suffire pour vos besoins de portabilité ou d'isolement (si votre besoin s'arrête là) : pour la portabilité : fpm, etc…
pour l'isolement : les cgroups, etc…
Par contre, je ne parierai pas sur le projet de Lennart Poettering étant donné l'usine à gaz qu'est systemd…
Bref, tout ça pour dire que, Ok, Docker a amené quelques nouveautés impressionnantes/importantes à l'époque, allant même jusqu'à nous faire penser complètement différemment nos d'infras et nos développements, mais que ce n'est plus forcément le choix approprié quand il s'agit de portabilité (si l'on prend en compte la quantité d'utilisateurs - en moins - sur les autres technos).
Rémy
[^] # Re: Une sur-couche à Docker. Parce que docker est mal pensé.
Posté par xcomcmdr . Évalué à 3.
Pour ma part je suis passé d'une usine à gaz (SysV / Upstart) à un truc qui 'juste marche' (systemd), et je ne regrette pas une seconde le passé.
A mon avis, tu es très mal informé sur systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Une sur-couche à Docker. Parce que docker est mal pensé.
Posté par remyd1 . Évalué à 1.
Bonjour,
Je ne conteste pas le fait que systemd fonctionne bien, je dis juste qu'un d'un point de vue technique - et non fonctionnel - on n'est très loin de la philosophie KISS…
Rémy
# Securite
Posté par cedric . Évalué à 6.
Il n'y a que moi que ca derange cette approche du courcircuitage des distributions pour aller plus vite dans la gestion des problemes de dependences… sans addresser un moyen robuste de mettre a jour les tonnes de bibliotheque duplique !?! Heureusement que Linux sur le Desktop, c'est pas pour demain, sinon on est bien parti pour faire aussi bien que Windows…
[^] # Re: Securite
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Salut Cédric,
La déduplication envisagée avec OSTree et le systèmes de couches déjà en place avec Docker permettent de profiter en partie des dépendances déjà installées.
Les conteneurs sont une solution intéressante, notamment pour des applications en lesquelles tu n'as pas confiance, après je ne pense pas que le but est de remplacer les gestionnaires de paquets de ta distro, et pour ma part je préfère nettement un truc déjà intégré dans ma Debian ou autre, mais je suis content d'installer un truc tiers ou à tester avec gestion des permissions très facilement.
# Les pâques sont passées pour le projet Subuser
Posté par shann . Évalué à 1.
Bonjour la compagnie,
Avant toutes choses, je vous souhaites de joyeuses pâques.
Ce matin en me réveillant, j'ai eu la surprise de voir en plus des oeufs, deux sachets étranges l'un avait un spirale et l'autre de drôles d'initiales "RPM" :-).
Tout ce petit monde est disponible sur le dépôt github suivant Subuser packaging.
Le README indique la marche à suivre pour l'installation.
Celui-ci n'est pas à l'abri de coquilles, ou d'axe d’améliorations :-).
Have fun.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.