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.
À 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 "
,"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 essaye 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 boite 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).
Source : http://linuxfr.org/news/subuser-une-sur-couche-a-docker
