Version imprimable
Bonjour,
La fonction fopen ouvre a priori un fichier sur un disque.
Si je crée une zone mémoire quelconque dans un programme C, y a-t-il moyen de l'associer à un nom de fichier "virtuel" qu'on fournirait à fopen pour que l'identificateur FILE * renvoyé ne pointe pas sur un fichier du disque, mais sur la zone mémoire ? L'idée serait que cet identificateur, s'il est fourni à fread, fscanf, ... aille lire les données dans la zone mémoire.
Merci pour vos réponses.
Il me semble que c'est impossible avec la fonction fopen. :mrgreen:
Mais il faut chercher sur les Internets comme open_memstream.
Je soupçonne que cela doit être spécifique selon le système d'exploitation.
Édit: il y a peut-être sous Windows CreateFileMapping
Voire même fmemopen(), sur la page que tu cites…Citation:
Envoyé par foetus
Merci de ta réponse.
Néanmoins, je n'ai pas trop le choix. Je m'explique : je possède une bibliothèque objet dont je n'ai pas les sources et que je ne peux modifier. Cette bibliothèque contient une fonction qu'on doit tester et qui prend en entrée non pas seulement des variables diverses mais aussi un nom de fichier d'un type particulier qu'il lit. Et cette bibliothèque écrite en C standard utilise plus que sûrement fopen ainsi que fread pour lire dedans.
Autre problème, on doit faire ces tests par quelqu'un d'extérieur à qui on ne peut pas laisser accès aux fichiers pris en entrée car certaines parties, nécessaires, doivent rester confidentielles (ah, l'industrie ! :?). Or, ces parties peuvent être renconstituées. L'idée était alors de créer une base sans données confidentielle et faire un exécutable qui génère un fichier temporaire contenant ces données, appeler le module et effacer ensuite le fichier temporaire. La parano étant ce qu'elle est mais nous poussant à la prudence extrême, s'est posé le problème de celui qui casserait l'exécution du programme et qui donc aurait accès au fichier tempoarire avec les données secrètes et pourrait ainsi les vendre à la concurrence, la Chine, la Russie ou aux Pingouins d'Antarctique. Bonjour la prise de tête. :mur:
Bref, j'avais donc pensé à ce système de simuler un fichier en mémoire qui disparaîtrait en cas de kill -9 ou de Ctrl-C mal intentionné...
Si ce n'est pas possible, il restera juste à éliminer le testeur à la fin de son travail :mouarf:.
Je suppose que tu travailles sous Linux.
Utilise déjà ptrace et strace pour voir si c'est vrai.Citation:
Envoyé par olivier_u
Ensuite, tu peux utiliser la variable d'environnement LD_PRELOAD pour que ton programme soit lié en premier lieu aux bibliothèques dynamiques de ton crû avant les autres. Tu pourras alors y définir une fausse fonction fopen() qui s'appuiera éventuellement sur les autres.
Tu peux aussi tricher en créant à l'avance le fichier en question en tant que tube nommé ou socket associé à un autre programme qui, lui, contrôlera et enverra les données que tu veux que ton programme reçoive (ça risque de poser problème en cas de fseek()/rewind(), cela dit).
Ça ne servira à rien : un utilisateur averti reste toujours maître de sa machine et heureusement. Pour explorer le contenu de la mémoire d'un processus, il suffit de l'arrêter en cours d'exécution avec un débogueur comme gdb et de faire un dump des parties qui nous intéressent. Il est même possible d'accéder à cela via /proc/<PID du programme> et, en dernier recours, de faire une copie de /proc/kcore pour faire un snapshot de la mémoire entière et l'examiner à tête reposée.Citation:
Autre problème, on doit faire ces tests par quelqu'un d'extérieur à qui on ne peut pas laisser accès aux fichiers pris en entrée car certaines parties, nécessaires, doivent rester confidentielles (ah, l'industrie ! :?). Or, ces parties peuvent être renconstituées. L'idée était alors de créer une base sans données confidentielle et faire un exécutable qui génère un fichier temporaire contenant ces données, appeler le module et effacer ensuite le fichier temporaire. La parano étant ce qu'elle est mais nous poussant à la prudence extrême, s'est posé le problème de celui qui casserait l'exécution du programme et qui donc aurait accès au fichier tempoarire avec les données secrètes et pourrait ainsi les vendre à la concurrence, la Chine, la Russie ou aux Pingouins d'Antarctique. Bonjour la prise de tête. :mur:
Bref, j'avais donc pensé à ce système de simuler un fichier en mémoire qui disparaîtrait en cas de kill -9 ou de Ctrl-C mal intentionné...
Blague à part, c'est plutôt par cela qu'il faut commencer : pas par liquider le testeur bien sûr, mais à évaluer la probabilité qu'il en rentre en possession, ainsi que les risques et les pertes si jamais l'utilisateur y arrive effectivement. Souvent, la valeur des données à protéger reste inférieure au coût du système de sécurité à mettre en place. Et si c'est VRAIMENT trop sensible, alors il ne faut pas les diffuser du tout mais, au contraire, les protéger dans un datacenter blindé au trente-sixième sous-sol. Et si l'enjeu vaut effectivement d'investir dans de telles infrastructures, alors le plus simple consiste à mettre en place un serveur d'entreprise interrogé à distance qui, lui, fera les traitements et servira les informations nécessaires en fonction des données restées confidentielles. Et le plus beau, c'est que ce sera cent fois plus simple à mettre à jour.Citation:
Si ce n'est pas possible, il restera juste à éliminer le testeur à la fin de son travail :mouarf:.
Dans tous les cas, il s'agit de politique générale et de conception, qui doivent être menées en amont pour orienter ensuite le sens du développement.
Bonsoir,
N'étant pas revenu depuis six ans, j'adresse des remerciements tardifs à ceux qui m'ont conseillé.
Bonne année à tous.