Bonjour à toutes et à tous.
Je m'essaie depuis quelques temps à la programmation réseau. J'utilise pour ce faire la librairie Gnet couplée avec GTK.
Je désire scanner ma station de travail pour extraire tous les ports ouverts ( en TCP pour commencer ). Cette première étape ne pose pas de problème particulier. J'obtiens les ports ainsi qu'un socket sur chaque port.
La deuxième étape serait de trouver quelles applications ouvrent ces fameux ports. Un peu à la manière de netstat. Et là, je bloque. Je ne trouve aucune fonction qui me permette, à partir du port et/ou du socket de me renvoyer le PID de l'application incriminée.
Sauriez-vous éclairer ma lanterne ?
Forum Programmation.c Fonctions de recherche réseau
22
nov.
2005
# Propreté habituelle
Posté par Ph Husson (site web personnel) . Évalué à 2.
Facile: strace
Bon pour simplifier un maximum on fait séléctif on va prendre netstat -l -A inet -p
(donc que les ports écoutés et seulement en ipv4)
Bon ben regarde par toi meme c'est pas la peine d'essayer si t'as de la patience :p
Bon en gros il regarde tout les programmes dans /proc il regarde le n° systeme de socket et apres dans /proc/net/tcp (ou udp ou unix ou raw ou je sais pas quoi d'autre) et compare tout ca
Donc dans la liste des processus dans /proc//fd t'as la liste des "fichiers" ouverts en lien
un coup de ls -l et on voit que sur les vrai fichier c'est un lien normal
sinon c'est sous la forme socket:[n°]
Sur ce amuse toi bien :p
# Impossible d'obtenir le PID de cette façon
Posté par deneb . Évalué à 3.
# Je dis sans doute une bêtise...
Posté par liberforce (site web personnel) . Évalué à 4.
http://man.linuxquestions.org/?query=lsof§ion=0&(...)
# merci
Posté par gerald dumas . Évalué à 1.
Effectivement Ph Husson, il faut que je scrute tous les PID de /proc pour retrouver mes petits. Je voulais éviter de passer par ce genre de méthode, mais bon s'il n'y a pas d'autre solution...
Quant à votre solution, deneb, elle est intéressante mais ne correpsond pas au but que je me suis fixé. J'ai vraiment besoin de connaître l'application en cause. L'idée dans un premier temps serait de faire un lecteur fenêtré qui afficherait tous les logiciels qui ouvrent un port en TCP/UDP sur la station de travail.
Enfin, liberforce, je cherche à être indépendant de tout logiciel. Le plus simple pour moi serait d'utiliser la sortie de netstat -ltaupe par exemple, mais ca implique l'installation de netstat. Je souhaite faire un soft qui n'a besoin que de lui-même.
P.S. : Une question me vient à écrivant ces quelques lignes. Le répertoire /proc dépend de la configuration du noyau il me semble. Existe-t-il des systèmes linux/Unix dépourvus de cette fonctionnalité ?
[^] # Re: merci
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Il est globalement (sauf cas rare ou le serveur informe de son PID) impossible de dériver le PID d'un service depuis une connexion reseau externe. Pour plusieurs raison, la premiere etant que c'est inutile, la seconde que cela sera OS dependant alors que TCP/IP n'a pas pour but de l'etre, et la troisieme (que je vois) est quel PID le service te donnerai ? celui du listener ? celui du fork qui est a ton ecoute ? a l'ecoute d'une autre session TCP ?
Bref ca peut pas se faire via reseau.
Deuxiemement cela ne peut pas se faire autrement qu'en inspectant les tambouilles interne de l'OS hote car il n'existe pas non plus d'appel systeme permettant a un process de demander les fichiers (sous unix tout est fichier) ouverts par un autre process et generalement cela veut dire: application non portable et application root uniquement.
Quant à votre solution, deneb, elle est intéressante mais ne correpsond pas au but que je me suis fixé. J'ai vraiment besoin de connaître l'application en cause. L'idée dans un premier temps serait de faire un lecteur fenêtré qui afficherait tous les logiciels qui ouvrent un port en TCP/UDP sur la station de travail.
xterm -e 'sudo watch netstat -taupe' ?
Enfin, liberforce, je cherche à être indépendant de tout logiciel. Le plus simple pour moi serait d'utiliser la sortie de netstat -ltaupe par exemple, mais ca implique l'installation de netstat. Je souhaite faire un soft qui n'a besoin que de lui-même.
Oui en meme temps c'est comme cela que le bordel avance, passer son temps a faire et refaire les meme outils, meme pour apprendre est a mon avis une perte de temps et faire des gros outils tout en un complement contraire a la philosophie d'un unix.
C'est pas pour rien que les shells sont extremement utiles: c'est grace a la centaine de petits outils que nous pouvons interfacer ensembles (sort, uniq, cat, sed, perl (oui bon), awk, tail, grep, find & co).
Deuxieme chose comme dit plus haut acceder a toutes les entrees de /proc necessite forcement les droits admins, et passer une application UI (user interface) en full root c'est generalement une tres mauvaise idée.
P.S. : Une question me vient à écrivant ces quelques lignes. Le répertoire /proc dépend de la configuration du noyau il me semble. Existe-t-il des systèmes linux/Unix dépourvus de cette fonctionnalité ?
Reponse donnée plus haut: pour faire simple le /proc n'est pas normé c'est d'ailleurs pour cela qu'il existe des outils comme ps, lsof netstat, top & co qui eux ont des comportement un peu plus stables.
Il est peu probable qu'un analyseur de /proc linux fonctionne sous BSD et encore moins sous solaris.
[^] # Re: merci
Posté par gerald dumas . Évalué à 1.
Au vu des réponses données, il est impossible de le faire. Soit. Mais cela m'a permis d'en apprendre un peu plus sur le répertoire proc.
Je suis tout à fait d'accord sur le fait de créer un gui avec accés root, c'est pas bien ! Je me donne juste certains buts à atteindre pour mieux comprendre les différences processus.
Encore merci pour tes commentaires constructifs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.