[C]Redéfinir/capturer un syscall (et pas une fonction)

Bien le bonjour,

Je suis étudiant en informatique, et j'ai un projet dans lequel il faut coder un mini-shell, qui réimplémente "open", pour effectuer divers traitements.
Pour le codage du shell, OK ça va, pas de problèmes.
Le chargement et la compilation de la librairie dynamique qui redéfinit "open" avec LD_PRELOAD, ça roule (ça a l'air en tout cas).
Par contre après avoir testé, rien, le néant, pas de réaction, comme si mon "open" n'existait pas.

Hélas, je venait de brutalement apprendre qu'il y avait "open" et "open", la libc nous cache des choses...
D'après ce que j'ai compris, le "open" de la libc n'est qu'une fonction (section 3 du man), une pâle copie du véritable appel système qui lui est codé en asm, mais qui d'après ce que j'ai lu appelle le syscall presque immédiatement, elle effectue juste 2-3 verifications avant ça (merci de me corriger si je me trompe).
Apparemment on appelle ça un wrapper, pour nous éviter d'avoir à utiliser nous-même "syscall" si j'ai bien compris.

Et donc là est mon problème : ma fonction "open" sera utilisée lorsqu'une commande fera appel à open(3), mais si cette commande utilise directement le syscall, ben mon beau "open" customisé ne sert à rien, on n'y passe jamais. Et apparemment c'est le cas pour toutes les commandes utiles/interessantes du shell.

La seule chose que j'ai constatée, c'est que lorsque j'utilise une commande svn (ou man), du style "svn log", là mon "open" est pris, et du coup je vois toutes les ouvertures de fichiers (vu que je "printf" les arguments pour tester mon "open"). Du coup ben super, c'est marrant, je comprends bien que "svn" utilise le open(3) mais ça m'avance pas plus.

Du coup voila ou j'en suis, je cherche comment faire pour intercepter, ou redéfinir cet appel système...et c'est donc là que j'ai besoin de votre aide ^^

Bon je ne demande pas une solution toute faite, mais juste une piste, quelque chose pour m'aiguiller.
En fait, il faut "juste" que la commande passe par mon "open", c'est tout ^^.
Pour l'instant je regarde du coté de "ptrace", donc suivi de l'exécution d'un processus, et de ce qu'il a en mémoire, mais je patauge quand même...


Merci d'avance à ceux qui prendront la peine de me lire ! (et de me répondre bien sur ;-)

Fait un "objdump -T /bin/ta_commande" (ou /usr/bin/tacommande).
Tu verras les différents appels a la libc que fais ta commande. (rajoute | grep open pour filtrer au besoin).
Tu verras par exemple que "ls" ne fait pas d'appel à open... (en fait il fait appel à opendir qui fait un appel noyau à open, donc impossible d'intercepter le open).

Pour ton problème, j'ai eu à peu près la même chose. En fait il y a plusieurs types d'open :
le open à deux arguments (path, flag) et celui à 3 arguments (path, flag, mode)

Il y a egalement open64. C'est la même chose que open, mais ce dernier est très souvent utilisé par les diverses commandes. Donc ca peut venir de là.

Un ptit lien au cas ou : http://stackoverflow.com/questions/6...inux-sys-calls

Perso en ayant redefini open et open64, j'ai constaté que pour des commandes comme touch,less,cp par exemple, c'était open64 qui était appelé.

Après, y a certain appel que tu ne peux intercepter. Tel que la commande "passwd" qui fait un appel à open64, mais qui pour des raisons de sécurité t'empeche d'intercepter ce dernier.


ps : moi j'galère sur le minishell :P

Merci de ta réponse, je commençais un peu à désespérer ^^



Pas mal le coup du objdump, je connaissais pas. Par contre en ce qui me concerne, touch, ls et cp n'utilisent pas open64, je sais pas pourquoi...mystère mystère...

Pour les open a 2 ou 3 arguments j'avais réglé ça, mais effectivement, j'avais carrément passé le open64 ! J'avais bien lu le header et les sources de la libc, mais j'étais passé trop vite dessus... en fait j'ai vu openat et tout le reste et je m'étais dit que non c'était pas la peine de s'y intéresser de plus près. Argh l'erreur, on ne m'y reprendra plus.

Merci aussi pour le lien, c'est toujours instructif !

A part ça, je voulais essayer de redéfinir la fonction syscall() (on sort l'artillerie lourde) lorsqu'ell est appelée pour open, mais marche pas :-(

Du coup y'a pas de moyen de réimplémenter complètement open (dans l'exemple du sujet, le prof utilise ls quand même, alors que pour l'instant ls n'utilise pas ma lib).

Mais merci beaucoup pour ton aide, ça m'a débloqué !

Oui, j'ai constaté que l'exemple du prof était faux.
"ls" ne faisant pas d'appel à open via la libc (mais via le noyau)

A tout hasard, j'ai réimplémenté opendir. Mais ca change rien au probleme.
Dans le 1er exemple ("ls"), il faut tester si il y a un argument ; Si il y en a pas tu génère un message d'erreur ("pola no access read blabla...").
Cependant, c'est impossible à faire... tout simplement car le systeme UNIX te mettra automatiquement "." dans ton pathname de opendir.

Après tu peux le faire statiquement... mais bof quoi :aie:

Bref, pour moi le sujet est bancal :p

Ah, je suis pas fou quand même !!!

Parce que j'ai essayé de voir et de retourner le problème dans tous les sens, mais décidément j'en arrivait aussi toujours à la même conclusion...on peut pas savoir depuis le open si le fichier apparaissait explicitement sur la ligne de commande, et même si c'était le cas, il faudrait distinguer les commandes qui peuvent attendre un argument comme ls, de celles comme id, ou pwd.

Au pire on pourra toujours faire les controles pour l'accès en écriture, mais pas pour la lecture. Et comme tu dis, il faudrait faire ça statiquement, alors qu'on est sensé le faire dans le open.



Enfin bon, à l'assaut de la 3ème partie du sujet maintenant ^^ et encore merci !

Je n'ai pas compris pourquoi tu cherchais à intercepter les appels à open(). Tu es sûr que c'est la bonne façon de faire ?

En fait il s'agit d'un projet dans lequel on nous demande de "réimplémenter les appels à open". Le but était de vérifier que les fichiers que le open() ouvrirait sont sur la ligne de commande, et entourés de chevrons, entre autres.

exemple qui ne doit pas fonctionner : ls
exemple qui doit fonctionner : ls <.>

Et on doit utiliser LD_PRELOAD. Enfin on devait, c'est fini maintenant ^^

Pourquoi, tu vois une autre façon de faire ?