Dernière version: le 24/03/2004.
alink
- alink est un mini-projet de la spécialisation Systèmes,
Réseaux et Sécurité de l'EPITA.
- Le responsable du projet pour la promo 2005 est Laurent Bercot.
Organisation
Groupes
- Le projet doit être fait par groupes de 3 ou 4 étudiants.
- Les groupes sont formés à la discrétion des étudiants, ou
arbitrairement par le responsable de projet si des groupes ne sont pas
prêts à la date limite.
- Chaque groupe constitué doit envoyer avant la date limite un mail
au responsable de projet, précisant :
- La liste de tous les membres du groupe
- Le nom d'un membre du groupe qui sera le chef de projet,
c'est-à-dire l'interlocuteur unique du groupe avec le responsable de
projet.
Ce courrier électronique devra avoir pour sujet : Groupe de projet alink
- Tous les membres du groupe doivent bien sûr fournir un travail équivalent,
mais le chef de projet assure seul l'interface avec l'équipe pédagogique.
Calendrier
Le projet dure environ un mois et demi. Les étudiants sont, pendant
cette période, complètement autonomes ; leur seule contrainte est
la date de rendu du livrable.
- jeudi 25 mars 2004: date de publication du sujet.
- vendredi 9 avril 2004: date limite de
formation des groupes
- samedi 29 mai 2004: rendu du livrable par le chef de projet
Livrable
- Le sujet consiste en une certaine spécification,
volontairement incomplète, ainsi que certaines indications.
- Le travail demandé consiste en :
- L'implémentation exacte de la spécification donnée dans le sujet,
à partir d'un système de type Unix de votre choix dont les
sources doivent être disponibles
- L'écriture de spécifications complémentaires
- L'implémentation exacte de ces spécifications sur le même système
Il s'agit donc d'un travail autant d'analyse et de création que de
réalisation.
- Le livrable consiste en :
- Un rapport imprimé, en français ou en anglais au choix du groupe,
documentant précisément les spécifications écrites, les outils
implémentés, etc. Ce rapport, joint au sujet, doit constituer
une spécification complète du concept d'active link, ainsi que
la documentation complète et correcte d'une implémentation de cette
spécification.
- Un support informatique - disquette ou CD-ROM - contenant :
- Une version électronique du rapport imprimé, sous un format
libre (de préférence texte, HTML, PDF ou Postscript)
- Le code source de l'implémentation documentée. Pour chaque
partie de l'implémentation (noyau, libc, divers programmes userland)
il pourra s'agir d'un code source complet assorti d'instructions de
compilation et d'installation, ou d'un patch assorti des mêmes
instructions et de la référence précise du logiciel sur lequel le
patch doit être appliqué. Dans le cas d'un code source complet,
attention à respecter les clauses de redistribution des logiciels
modifiés.
Conseils
- La maîtrise de la langue est fondamentale. Quelle que soit la langue
choisie, faites attention à votre orthographe, votre grammaire et votre
style - cela peut vous rapporter des points, ou vous en enlever beaucoup
(beaucoup) si votre rédaction est pénible à lire.
- Une mauvaise idée documentée vaut mieux qu'une bonne idée non
documentée. Les bonnes idées documentées sont encore meilleures.
- Ce qui sera utilisé comme référence n'est pas votre code source,
mais votre documentation. Si votre code s'écarte de ce que vous avez
spécifié, c'est un bug. Prenez-y garde.
- Examinez bien toutes les implications de vos choix avant de vous
lancer dans une implémentation que vous risquez de trouver trop complexe
au bout de quelques jours.
- Un projet qui marche presque est un projet qui ne marche
pas du tout, et qui sera noté comme tel, sans tenir compte de la quantité
de travail que vous aurez pu fournir dessus ; seul le résultat final
est pertinent. Pensez à finaliser votre travail, en particulier
prévoyez une large phase de tests.
- Beaucoup de temps vous est laissé pour que vous puissiez travailler
sur ce projet dans de bonnes conditions; en contrepartie, un travail bâclé
sera noté sans indulgence. Mettez à profit le temps dont vous disposez,
réfléchissez au sujet dès que vous en avez l'occasion, et ce, dès à
présent. N'attendez pas la dernière minute pour vous mettre au travail.
- Le responsable de projet est là pour vous aider si vous avez des
difficultés. N'hésitez pas à le contacter.
Technique
Spécification
alink
Un alink, ou active link, ou lien actif, est
une extension proposée d'UNIX. Il s'agit d'un nouveau type de fichier,
inspiré des liens symboliques (symlinks).
Quand le système résout un symlink, il lit le contenu du fichier, et
ce contenu est le résultat souhaité. Quand le système résout un alink,
il lit le contenu du fichier ; ce contenu est le chemin d'accès à un
programme exécutable, appelé programme d'indirection, situé
dans le filesystem. Ce programme est exécuté, et le résultat souhaité
est ce qu'il imprime lors de son exécution.
La structure d'un alink est très semblable à celle d'un
symlink ; la différence essentielle est que la donnée
contenue dans le lien n'est pas le nom de fichier pointé, mais le nom
d'un programme qui, exécuté, renverra le nom de fichier pointé. Le
chemin d'accès au programme peut être absolu ou relatif à l'emplacement
du alink ; de même, le retour du programme peut être
absolu ou relatif à l'emplacement du alink.
Le type de fichier alink doit s'intégrer de façon parfaitement
transparente dans le système d'exploitation et en particulier dans le
système de résolution de liens symboliques. Notamment, la résolution
des alinks doit fonctionner dans tous les cas : alink
pointant vers un alink ou vers un symlink, symlink pointant vers un alink...
Pour permettre à certains programmes de manipuler des alinks
de façon spécifique, deux appels systèmes seront ajoutés au noyau
choisi :
- readalink(), à comparer avec readlink()
- astat(), à comparer avec lstat()
L'interface et la sémantique précises de ces nouveaux appels système
sont au choix ; chaque choix devra être décrit en détail et justifié.
Il est autorisé de modifier la libc du système utilisé, ainsi que de ne
pas le faire et de fournir les interfaces C supplémentaires dans une
bibliothèque séparée, statique et dynamique. Dans ce cas, le
mode opératoire de compilation devra être soigneusement documenté.
Les programmes d'indirection
Un processus d'indirection, instance d'exécution d'un programme
d'indirection, doit être considéré comme un fils du programme ayant accédé
au alink. Il hérite donc de tout son environnement d'exécution, à
deux exceptions près :
- Le descripteur de fichier 0 est fermé
- Le descripteur de fichier 1 n'est pas le même que celui du processus
appelant. C'est un descripteur ouvert en écriture, sur lequel le programme
d'indirection écrit le résultat de la résolution du alink. Ce
résultat sera utilisé verbatim par le noyau.
Le programme d'indirection prend un argument sur la ligne de commande,
qui est le nom de l'alink qui a causé son exécution. Son code
de retour doit être 0 pour que l'appel système nécessitant une résolution
d'alink retourne avec succès. Tout autre code de retour
provoquera un échec de l'appel système ; la variable errno
devra alors avoir une valeur significative, justifiée, et conforme à la
spécification de l'appel système.
À l'inverse d'un véritable fils du processus appelant, un processus
d'indirection doit être parfaitement invisible pour le processus appelant.
En particulier, sa mort ne doit jamais provoquer de SIGCHLD, et le PID
du processus d'indirection ne doit jamais être renvoyé si le processus
appelant effectue un appel système de type wait.
Userland
Afin de permettre la manipulation des alinks, il devra être
fourni des utilitaires spécifiques, ou des versions modifiées de certains
programmes userland. Les modifications pourront être apportées sur des
implémentations existantes de ces programmes, ou bien les programmes
pourront être entièrement réécrits, au choix. Les changements de
comportement par rapport à la norme ou à l'implémentation existante sont
autorisés, pourvu qu'ils soient dûment documentés et justifiés.
Sont obligatoires :
- Un programme permettant de lire le contenu d'un alink,
apportant une fonctionnalité équivalente à celle de readlink ou de
linkname
mais pour les alinks. Il peut s'agir d'une option supplémentaire à
linkname, ou d'un programme séparé alinkname.
- Des programmes permettant de copier, déplacer et supprimer des
alinks. Un bonus sera accordé si la gestion des alinks
est implémentée comme une extension aux outils standard cp,
mv et rm.
- Un programme permettant de créer un alink. Un bonus sera
accordé s'il s'agit d'une extension au programme
minln
ou à l'outil standard ln.
- Une implémentation de ls prenant en compte l'affichage des
alinks lors de l'utilisation des options -l et -F.
La façon dont apparaissent les fichiers de type alink est au choix
- documenté et justifié.
Sont facultatifs :
- Une implémentation de find permettant une recherche de
fichiers de type alink
- Une implémentation de tar conservant les alinks
dans les archives créées, et les extrayant correctement.
Indications
- La norme est toujours le comportement de référence du
système sur lequel vous travaillez. La cohérence entre vos ajouts et
le comportement existant du système est fondamentale. Toutefois, il
est souhaitable - en particulier pour les programmes userland -
d'écrire le code le plus portable possible. La référence en matière de
portabilité est la
Single
Unix Specification version 3. Dans le doute, ou même dans la
certitude, consultez-la et suivez-la.
- Pour assurer la transparence du alink par rapport au
reste du système, vous serez appelé à modifier un certain nombre de
parties du noyau. Il vous appartient d'isoler ce qui doit être modifié
et ce qui ne le doit pas, en justifiant - comme toujours - vos choix.
Voici une liste non exhaustive des appels système devant être modifiés :
- _exit()
- readlink()
- open()
- access()
- stat(), lstat()
- rename()
- ainsi qu'un certain nombre d'appels spécifiques au système choisi.
Exemple
$ id
uid=588(ska), gid=100(users), groups=100(users)
$ pwd
/home/ska
$ cat mytmp.c
#include <unistd.h>
#include <sys/types.h>
#include <pwd.h>
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
int main ()
{
struct passwd *pw = getpwuid(getuid()) ;
if (pw == NULL)
{
perror("mytmp: unable to find user name") ;
if (errno == 0) errno = ENOENT ;
return errno ;
/* assuming the kernel interprets the exit code as the right errno to provide */
}
printf("/tmp/%s", pw->pw_name) ;
return 0 ;
}
$ gcc -o bin/mytmp mytmp.c
$ minln -a bin/mytmp kikoo
$ ls -l kikoo
arwxrwxrwx 1 ska users 9 Mar 16 15:00 kikoo -> bin/mytmp
$ cd kikoo
cd: no such file or directory: kikoo
$ mkdir /tmp/ska
$ cd kikoo
$ pwd
/tmp/ska