Wine est un instrument merveilleux pour tous ceux qui ne veulent plus de Windows, mais ne peuvent pas non plus se passer entièrement d’une poignée d’applications dont les équivalents sous OS libre sont décevants. Ainsi, pour les maniaques de la copie audio parfaite, Exact Audio Copy est largement supérieur à Rubyripper (moins efficace et dont le développement a cessé) ou à Morituri (sans aucune souplesse en ce qui concerne les tags).
Cependant, Wine a un inconvénient majeur : il ouvre la machine aux menaces spécifiques à Windows. Sur les forums, on lit souvent des réponses à ce problème du type : « Mais comme on ne lance pas Wine en root, on ne compromet pas sa machine. » Certes, mais on expose toutes les données auxquelles l’utilisateur de l’application a accès, ce qui est très suffisant pour faire peur…

Les méthodes de sécurisation les plus simples (comme winetricks sandbox, qui supprime des lecteurs avec winecfg) n’étant pas très efficaces, mieux vaut se tourner vers la virtualisation. Cependant, outre que cette solution est lourde, EAC ne fonctionnera pas correctement sur un Wine de machine virtuelle Virtualbox, à cause du pilote virtualisé du CD-ROM.

Sous FreeBSD, il suffit de faire tourner Wine dans une jail. Mais sous Linux, la mise en place de container LXC était une opération lourde, assez décourageante pour un besoin aussi basique.

La donne a cependant changé avec l’arrivée de Docker : il devient en effet assez facile de créer un container pour faire tourner une application graphique sous Wine.

Voici comment je m’y suis pris.

Fichier Dockerfile pour créer le container :

:::text
FROM ubuntu:

ENV DEBIAN\_FRONTEND noninteractive

RUN apt-get update -y  
RUN apt-get install -y python-software-properties software-properties-common
RUN add-apt-repository -y ppa:ubuntu-wine/ppa  
RUN dpkg --add-architecture i386  
RUN apt-get update -y  
RUN apt-get install -y wine1.7 winetricks  
RUN apt-get purge -y python-software-properties  
RUN apt-get autoclean -y

\# Remplacer 1002 & 100 avec user & group id  
RUN export uid=1002 gid=100 && \
    mkdir -p /home/developer && \
    echo "developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash" >> /etc/passwd && \
    echo "developer:x:${uid}:" >> /etc/group && \
    echo "developer ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/developer && \
    chmod 0440 /etc/sudoers.d/developer && \
    chown ${uid}:${gid} -R /home/developer

USER utilisateur  
ENV HOME /home/utilisateur  
CMD /usr/bin/wine

Un petit coup de docker build utilisateur/wine.
Le container est construit. Reste qu’il ne faut pas y placer les données, si on veut pouvoir le faire évoluer et se mettre à jour. Le plus pratique pour pouvoir aussi échanger des fichiers entre l’hôte et le container est de créer un dossier Wine sur l’hôte qu’on montera comme home dans le container avec : -v emplacement-dossier-Wine:/home
Il faut créer à l’intérieur un dossier au nom de l’utilisateur : mkdir utilisateur
Pour rediriger le container vers la sesson X de l’hôte : -e DISPLAY=\$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix

Ce qui donnera, pour ouvrir un shell dans le container :
docker run -ti --rm -e DISPLAY=$DISPLAY -v emplacement-dossier-Wine:/home -v /tmp/.X11-unix:/tmp/.X11-unix utilisateur/wine /bin/bash

Il faut ensuite créer un environnement wine pour 32 bits, ce qu’on peut faire avec l’instruction dans le shell ouvert dans le container :
WINEARCH=win32 winecfg

On procède ensuite, toujours dans le shell à l’installation normale d’une application wine. On l’essaie ensuite en la lançant depuis le shell. Si tout marche correctement, on peut ensuite se fabriquer un lanceur depuis l’hôte, de type :
docker run -ti --rm -e DISPLAY=$DISPLAY -v emplacement-dossier-Wine:/home -v /tmp/.X11-unix:/tmp/.X11-unix utilisateur/wine /bin/sh -c "cd /home/utilisateur/.wine/drive_c/Program\ Files/Programme/ && wine Prgramme.exe"

Le container se lance et se ferme en même temps que l’application. Voilà notre vin en sécurité dans le bac à sable…