Tout comme Mbox, ils utilisent seccomp-bpf couplé à ptrace (SECCOMP_RET_TRACE). Cela a deux avantages:
grâce à seccomp-bpf, seuls les appels systèmes dit "intéressant" provoquent un déroutement de l'exécution, c'est donc moins coûteux que PTRACE_SYSCALL où le processus est arrêté à chaque appel système, une fois en entrée et une fois en sortie.
grâce à ptrace, il possible d'appliquer des règles qui seraient impossible à écrire avec la syntaxe PBF, comme par exemple interdire open("/etc/fstab", …) mais autoriser tous les autres open(). Il est même possible de modifier les paramètres des appels systèmes (c.f. PRoot).
Pourquoi avoir décidé de repartir à zéro plutôt que d'améliorer, forker ou devenir les mainteneurs de CDE ? (Ce n'est pas une
critique.)
CARE n'est pas écrit depuis rien, il se base massivement sur PRoot: techniquement seulement 15% du code de CARE est exclusif, tout le reste provient de PRoot. Ce dernier était initialement une implémentation en mode utilisateur de quelques fonctionnalités noyau, mais au fil du temps il est devenu une base pour d'autres outils souhaitant aussi observer et/ou manipuler des processus sous Linux (CARE en est un exemple typique). En fait, c'est une personne à qui nous étions en train de présenter PRoot qui nous demandé comment celui-ci se comparait à CDE, et ce malentendu c'est transformé en CARE :)
Pourquoi créer des archives autoextractibles ? Le format le plus standard sur les machines cibles (sous linux) est tar.gz, les
archives auto-extractibles n'ont jamais été répandues sur cette plateforme, et le code exécutable additionnel peut être source de
bugs et ne peut pas être maintenu une fois l'archive produite.
Il est aussi possible de produire des archives au format .tar.gz directement, il suffit de le préciser:
$ care -o foo.tar.gz <command>
En ce qui concerne le choix du format auto-extractible, comme cela est expliqué dans ce commentaire, l'une des raisons principales est justement que GNU tar contient des bugs. Cependant, afin de rassurer les utilisateurs sur la pérennité de leurs archives auto-extractibles, il existe une documentation sur comment arracher l'archive interne—au format .tar.lzo par défaut—de son enveloppe exécutable.
On pourrait directement imaginer aussi des truc du genre
[terminal] $ care -f tar -o >( bufcat | gzip | ssh host "cat > care-archive.tar.gz" ) some_stuff
Oui, je sais, ma haine des fichiers temporaires est maladive. Mais globalement je trouve ton programme absolument génial à ce détail près
J'aime bien l'idée du compresseur "quelconque" qui tourne à l'extérieur de CARE, ainsi que le transfert réseau à la volé ; c'est très utile sur des plates-formes où l'espace disque est très faible. Même si c'est faisable avec un tube nommé, l'option -f est bien plus élégante ; j'achète donc ton idée avec plaisir :D Ce sera disponible certainement dans la prochaine version.
et aussi à mon incompréhension des autoextractibles, mais ça ne doit pas correspondre à mon usage.
Dans le cas de CARE, il y a deux raisons pour l'usage par défaut du format auto-extractible. La première est une volonté forte de ne dépendre de rien lors de la ré-exécution, c'est pour cela que proot est intégré dans l'archive par exemple: il n'y a pas besoin de récupérer un "player" comme on peut le voir avec des VMs. La seconde raison est plus technique, il s'agit d'éviter des bugs connus dans des outils tels que GNU tar ou GNU cpio (on ne peut pas faire l'hypothèse que l'utilisateur aura une version corrigée, d'autant plus qu'elle n'existe pas aujourd'hui). Pour faire court, ces bugs sont très facilement exposés avec CARE (de part sa nature "dynamique") mais ils peuvent être reproduit avec GNU tar aussi. Par exemple:
$ touch foo
$ mkdir a
$ chmod -w a
$ tar -cf test.tar a
$ chmod +w a
$ touch a/b
$ chmod -w a # la restoration des droits est optionnelle
$ tar -rf test.tar foo a/b
$ tar -xf test.tar
tar: a/b: Cannot open: Permission denied
C'est un problème qui n'est pas corrigé dans GNU tar, qui est corrigé que partiellement dans GNU cpio, mais complétement dans libarchive. CARE se base donc sur ce dernier pour fournir l'option -x et le format auto-extractible.
Pour une appli KDE ou Gnome, ca peut poser des problèmes car les applications dépendent d'autres services lancées par le desktop (dbus, …), qui sont accédés via un mécanisme d'IPC. Donc ça ne sera pas embarqué dans l'archive.
Pour résoudre ce problème de dépendance à des services "externes", la notion de chemins et variables d'environnement "volatiles" a été introduite dans CARE. Ceux-ci ne sont pas archivés, mais comme "ré-injecté" dynamiquement dans l'archive depuis le système où l'on ré-exécute. Par défaut (on peut les enlever ou en ajouter) les chemins volatiles sont:
/dev
/proc
/sys
/run/shm
/tmp/.X11-unix
/tmp/.ICE-unix
$XAUTHORITY
$ICEAUTHORITY
/var/run/dbus/system_bus_socket
/var/tmp/kdecache-$LOGNAME
et les variables d'environnement volatiles sont:
DISPLAY
http_proxy
https_proxy
ftp_proxy
all_proxy
HTTP_PROXY
HTTPS_PROXY
FTP_PROXY
ALL_PROXY
DBUS_SESSION_BUS_ADDRESS
SESSION_MANAGER
XDG_SESSION_COOKIE
Cela implique que le système où l'on ré-exécute possède un service "compatible", ou bien d'archiver le service avec. Par exemple en démarrant KDE sous CARE, comme tu l'as suggèré.
La bonne manière de faire est probablement de démarrer carrément KDE avec CARE, mais bonjour la taille de l'archive !
Je viens de tester "care startkde" en laissant bien le temps à KDE d'accéder à toutes ses ressources (icons, .desktop, …): le .bin fait 203Mo et le .tar.xz fait 95Mo. À noter qu'il n'y a pas le serveur X dans cette archive.
Et encore, est-ce que CARE gère les forks et continue à suivre les deux processus ?
Oui, il n'y a vraiment aucun soucis avec les applications multi-processus et/ou multi-threadées.
un firefox passé dans care "pèse" combien ? 50 Mo ? 100 Mo ? 500 Mo ?
Réponse courte: entre 50 et 100 Mo.
Réponse longue: sur ma Slackware64-14.1, l'archive de Firefox 24.2.0 pèse 94 Mo par défaut:
$ care -o foo.bin firefox
[...]
$ du -h foo.bin
94M foo.bin
Il est possible d'avoir une archive encore plus petite en demandant à CARE de compresser avec l'algo. de "gzip" plutôt que celui de "lzo":
$ care -o foo.tgz.bin firefox
[...]
$ du -h foo.tgz.bin
75M foo.tgz.bin
Et si cela est encore trop gros, il suffit de dire à CARE de ne pas compresser à la volée, et d'utiliser un compresseur plus puissant a posteriori:
$ care -o foo.tar.bin firefox
[...]
$ du -h foo.tar.bin
224M foo.tar.bin
$ xz -9 foo.tar.bin
$ du -h foo.tar.bin.xz
48M foo.tar.bin.xz
Dans ce dernier cas, un outil externe (unxz) sera nécessaire pour décomprésser l'archive avant la re-exécution, ce qui n'est pas le cas lorsqu'on laisse CARE faire la compression (moins performante en taille, mais aussi moins gourmande en temps).
pour une application qui fait appel à des boites de dialogue gnome ou kde, ça aspire tout gnome/kde ?
Pour cet exemple, CARE va aspirer les bibliothèques graphiques (libgtk.so ou libqt.so) mais il n'aspirera pas les programmes qui ont été lancés avant lui (gnome ou kde). Il est cependant possible de démarrer gnome ou kde (et même X) sous le contrôle de CARE.
Les archives produites par CARE sont relativement petites car elles contiennent uniquement les fichiers nécessaires et sont compressées à la volée (par défaut). Par exemple, l'archive CARE sur le script suivant est de seulement 42 Mo:
tar -xf perl-5.18.1.tar.gz
cd perl-5.18.1
./configure.gnu
make -j 4
Dans ces 42Mo sont compris : les sources de Perl, les programmes Bash, GNU Make, GCC, ainsi que tous les autres programmes et fichiers qui ont été utilisés.
Du coup ca permet de faire des 'bundles' pour distribuer une appli, par exemple?
Exactement.
et au niveau des libs 32 et 64 bits par exemple?
Les libs nécessaires sont forcément archivées lors de l'exécution originale. Du coup, ce sont celles-ci qui seront ré-utilisées lors de la re-exécution, peu-importe quelles soient 32 ou 64 bits.
Pour le moment seuls les fichiers et répertoires utilisés sont archivés. Afin de répondre à ton besoin, je viens d'ajouter une tâche dans le tracker. En attendant, il faut que tu accèdes aux fichiers explicitement, par exemple:
# Autres projets utilisant seccomp-bpf
Posté par cedric-vincent . En réponse au journal Seccomp, une sandbox intégrée au noyau Linux…. Évalué à 4.
Voici deux autres projets utilisant seccomp-bpf:
PRoot: http://proot.me
Sydbox: http://dev.exherbo.org/~alip/sydbox/sydbox.html
Tout comme Mbox, ils utilisent seccomp-bpf couplé à ptrace (SECCOMP_RET_TRACE). Cela a deux avantages:
grâce à seccomp-bpf, seuls les appels systèmes dit "intéressant" provoquent un déroutement de l'exécution, c'est donc moins coûteux que PTRACE_SYSCALL où le processus est arrêté à chaque appel système, une fois en entrée et une fois en sortie.
grâce à ptrace, il possible d'appliquer des règles qui seraient impossible à écrire avec la syntaxe PBF, comme par exemple interdire open("/etc/fstab", …) mais autoriser tous les autres open(). Il est même possible de modifier les paramètres des appels systèmes (c.f. PRoot).
[^] # Re: CDE: Automatically create portable Linux applications
Posté par cedric-vincent . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 2.
Salut JGO,
CARE n'est pas écrit depuis rien, il se base massivement sur PRoot: techniquement seulement 15% du code de CARE est exclusif, tout le reste provient de PRoot. Ce dernier était initialement une implémentation en mode utilisateur de quelques fonctionnalités noyau, mais au fil du temps il est devenu une base pour d'autres outils souhaitant aussi observer et/ou manipuler des processus sous Linux (CARE en est un exemple typique). En fait, c'est une personne à qui nous étions en train de présenter PRoot qui nous demandé comment celui-ci se comparait à CDE, et ce malentendu c'est transformé en CARE :)
Il est aussi possible de produire des archives au format .tar.gz directement, il suffit de le préciser:
En ce qui concerne le choix du format auto-extractible, comme cela est expliqué dans ce commentaire, l'une des raisons principales est justement que GNU tar contient des bugs. Cependant, afin de rassurer les utilisateurs sur la pérennité de leurs archives auto-extractibles, il existe une documentation sur comment arracher l'archive interne—au format .tar.lzo par défaut—de son enveloppe exécutable.
[^] # Re: Le format du fichier de sortie
Posté par cedric-vincent . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 8.
J'aime bien l'idée du compresseur "quelconque" qui tourne à l'extérieur de CARE, ainsi que le transfert réseau à la volé ; c'est très utile sur des plates-formes où l'espace disque est très faible. Même si c'est faisable avec un tube nommé, l'option -f est bien plus élégante ; j'achète donc ton idée avec plaisir :D Ce sera disponible certainement dans la prochaine version.
Dans le cas de CARE, il y a deux raisons pour l'usage par défaut du format auto-extractible. La première est une volonté forte de ne dépendre de rien lors de la ré-exécution, c'est pour cela que proot est intégré dans l'archive par exemple: il n'y a pas besoin de récupérer un "player" comme on peut le voir avec des VMs. La seconde raison est plus technique, il s'agit d'éviter des bugs connus dans des outils tels que GNU tar ou GNU cpio (on ne peut pas faire l'hypothèse que l'utilisateur aura une version corrigée, d'autant plus qu'elle n'existe pas aujourd'hui). Pour faire court, ces bugs sont très facilement exposés avec CARE (de part sa nature "dynamique") mais ils peuvent être reproduit avec GNU tar aussi. Par exemple:
C'est un problème qui n'est pas corrigé dans GNU tar, qui est corrigé que partiellement dans GNU cpio, mais complétement dans libarchive. CARE se base donc sur ce dernier pour fournir l'option -x et le format auto-extractible.
[^] # Re: Jusqu'où aller ?
Posté par cedric-vincent . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 7.
Pour résoudre ce problème de dépendance à des services "externes", la notion de chemins et variables d'environnement "volatiles" a été introduite dans CARE. Ceux-ci ne sont pas archivés, mais comme "ré-injecté" dynamiquement dans l'archive depuis le système où l'on ré-exécute. Par défaut (on peut les enlever ou en ajouter) les chemins volatiles sont:
et les variables d'environnement volatiles sont:
Cela implique que le système où l'on ré-exécute possède un service "compatible", ou bien d'archiver le service avec. Par exemple en démarrant KDE sous CARE, comme tu l'as suggèré.
Je viens de tester "care startkde" en laissant bien le temps à KDE d'accéder à toutes ses ressources (icons, .desktop, …): le .bin fait 203Mo et le .tar.xz fait 95Mo. À noter qu'il n'y a pas le serveur X dans cette archive.
Oui, il n'y a vraiment aucun soucis avec les applications multi-processus et/ou multi-threadées.
[^] # Re: Jusqu'où aller ?
Posté par cedric-vincent . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 5.
Afin de compléter la réponse de Rémi,
Réponse courte: entre 50 et 100 Mo.
Réponse longue: sur ma Slackware64-14.1, l'archive de Firefox 24.2.0 pèse 94 Mo par défaut:
Il est possible d'avoir une archive encore plus petite en demandant à CARE de compresser avec l'algo. de "gzip" plutôt que celui de "lzo":
Et si cela est encore trop gros, il suffit de dire à CARE de ne pas compresser à la volée, et d'utiliser un compresseur plus puissant a posteriori:
Dans ce dernier cas, un outil externe (unxz) sera nécessaire pour décomprésser l'archive avant la re-exécution, ce qui n'est pas le cas lorsqu'on laisse CARE faire la compression (moins performante en taille, mais aussi moins gourmande en temps).
Pour cet exemple, CARE va aspirer les bibliothèques graphiques (libgtk.so ou libqt.so) mais il n'aspirera pas les programmes qui ont été lancés avant lui (gnome ou kde). Il est cependant possible de démarrer gnome ou kde (et même X) sous le contrôle de CARE.
[^] # Re: statifier un programme?
Posté par cedric-vincent . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 6.
Les archives produites par CARE sont relativement petites car elles contiennent uniquement les fichiers nécessaires et sont compressées à la volée (par défaut). Par exemple, l'archive CARE sur le script suivant est de seulement 42 Mo:
Dans ces 42Mo sont compris : les sources de Perl, les programmes Bash, GNU Make, GCC, ainsi que tous les autres programmes et fichiers qui ont été utilisés.
[^] # Re: statifier un programme?
Posté par cedric-vincent . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 4.
Exactement.
Les libs nécessaires sont forcément archivées lors de l'exécution originale. Du coup, ce sont celles-ci qui seront ré-utilisées lors de la re-exécution, peu-importe quelles soient 32 ou 64 bits.
[^] # Re: Gestion de la liste des fichiers
Posté par cedric-vincent . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 7.
Pour le moment seuls les fichiers et répertoires utilisés sont archivés. Afin de répondre à ton besoin, je viens d'ajouter une tâche dans le tracker. En attendant, il faut que tu accèdes aux fichiers explicitement, par exemple:
à la place de: