C'est à ça que sert le SETUID bit http://en.wikipedia.org/wiki/Setuid

Oui non du tout si si.
Tu as tout à fait raison: c'est ce que je devais une fois pour toutes lire/entendre/me dire.
Donc, si je dois laisser tomber une contrainte, il est évident, que c'est du root.
Mais c'est dur...

Peut-être que si je donne un peu plus d'info sur le contexte: une machine (serveur) chez un client, avec un agent SNMP de health-monitoring (hdd, cpu, mem, ...et fatalement réseau) doit faire un peu de 'popote' interne pour retrouver toutes les stats à afficher pour peupler ses variables et donc pas mal d'appels systèmes (POSIX/*NIX-like)
L'avantage des netstat, vmstat etc...c'est que c'est tout à fait 'callable' en usermode.
J'espérait trouver quelque chose de la sorte.

Mais le point important c'est que, aujourd'hui, j'ai une partie de ma réponse: l'info n'existe pas directement quelque part dans le kernel, il faut l'aggréger. Et donc commencer à compter, par port, les bytes/packets.
J'ai des réponses fortement libcap, d'autres en iptables, je vais un peu tripatouiller tout cela.

Oui mais excuse-moi de venir jouer le troublion mais d'un coté, tu veux un truc léger, user-mode mais en passant, tu veux des stats précises sur des infos systèmes.

Le nombres de paquets échangés par connexion, tu peux te toucher, par défaut.

Le coût du connection tracking (ip conntrack), ça peut le faire (je sais pas s'il garde des stats mais soit, c'est une optique), mais encore une fois... faudra en passer par root à un moment ou à ... un moment.

Pour IPTraf:

IPTraf intercepts packets using the built-in raw socket interface of the Linux kernel. It will therefore work with any kernel-supported interface.

Y a pas de secret ma poule ... c'est root ... ou c'est mort. A moins de foutre un proxy entre tous les ports que tu veux monitorer (et encore ... si c'est pour binder du < 1024 c'est mort).

Courage, mais va falloir revoir les requirements ...

Merci d'avoir pris le temps de répondre ces pistes!

ntop> ah oui ça c'est superbe, mais:
- c'est un peu la tronçonneuse pour couper des allumettes.
- c'est fortement libpcap (donc root?), pas certain que je puisse déballer cela chez le client (stupid-usermode only)
--> j'installe et je teste quand même.


Que QUOI QUI?!
WOWOWOWOWWO?!
Mais j'ai pas ça moi? SuSE? *buntu? debian? c'est un module en plus?
--> je cherche (et je teste)


ipTraf> rah voila l'affichage erectif que je cherche à obtenir, en effet:
http://iptraf.seul.org/shots/iptraf-tcpudp.gif
Mais je dois un peu voir le moteur qu'il y a derrière.
--> j'installe et je teste quand même.

IPTraf

/proc/net/ip_conntrack est une autre source de réponse

Jette un oeil à "ntop"

http(s)://localhost:3000

TCP/UDP Port Total Sent Rcvd
ssh 22 60,1 MBytes 58,2 MBytes 1,9 MBytes
[...]

Plus graphs & zo voor

A+

Je devrais trouver le nombre de bytes (allez, soyons fous, cela peut même être boolien: y en a, ou y en a pas) échangés (allez, soyons fous, cela peut même être Rx et Tx confondus) par port TCP.

Les pistes:
- un argument en plus dans netstat pour affichier les bytes par connection ESTABLISHED (solution rêvée!) ?
- un tirroir secret dans /proc ?
- un outil *nix qui le fait déjà?
- une crasse de script tout fait du net?

En gros, c'est de savoir si l'info existe dans le kernel et si elle peut être dispo dans l'userspace d'une manière ou d'une autre...


Désamorçage de la réponse: il faut éviter les mots 'root' et 'tcpdump'.
Idéalement, ne réfléchissons pas en libpcap (sauf si on peut (par ex. python) en faire un petit script...lancé par un bête user)