Effectivement c'est pas magique et ça sait pas tout défaire mais il n'est quand même pas nécessaire de single-stepper explicitement. Il suffit de passer en mode « target record » et on peut reserve debugger à loisir ou presque à partir de ce moment.
Par contre il me semble que ODB garde bien une trace de tout l'état du programme à chaque instruction (comme s'il était en mode « target record » en permanence donc).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'était surtout pour rendre le titre « intéressant » :) Après dans l'article j'ai utilisé debugging pour mitiger la répetition parce que je vois pas beaucoup de synonymes possibles. Mais il est vrai que les italiques ou guillemets auraient pu être utilisées de manière plus cohérente.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Au cas où tu déciderais d'établir une communication constructive.
Malgré le manque de documentation et le peu d'explication, je pense avoir plus ou moins compris ce qu'est censé faire Clownix-Spy. Cependant, je m'interroge sur les choix techniques qui ont été réalisés.
Notamment, je crois comprendre que l'idée est de permettre l'observation de certains éléments interne au noyau. Cela nécessite cependant l'écriture de modules avec tous les risques et complications que cela comporte. Or, le projet SystemTap aborde déjà cette problèmatique et est relativement mature et intégré à plusieurs distributions. Ma question est donc : pourquoi ne pas se baser sur SystemTap ? Cela a-t-il été envisagé et rejeté ? Pourquoi ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
> J'y ai pensé, mais quand c'est freeze du système, il n'y a plus de sortie à la console.
Si. Mais pas dans les logs. Si t'as pas la possibilité de monter une console série, tu peux essayer netconsole. Mais bon, après, k(g)db redevient peut-être plus pratique aussi.
> Pour les while, c'est juste pour être sûr que j'obtient le lock.
J'ai pas regardé le code mais ça pue assez bien ton truc là, que ça soit lié au problème ou non.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Bien sûr qu'il a le choix pour débugger. Sans avoir à se mettre à k(g)db, il peut faire un sysrq-{w,t} quand le système est freezé et voir à quel endroit ça coince.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je n'ai jamais utilisé DTrace ni (Open)Solaris. J'utilise SystemTap et OProfile assez régulièrement mais pas forcément de manière très avancée.
De ce que j'en ai compris, DTrace a plus de fonctionnalités que SystemTap mais les développeurs stap travaillent à rattraper le retard. La version 1.0 est juste une continuité mais ne marque pas vraiment une avancée soudaine et importante.
OProfile n'est pas vraiment comparable à DTrace ou SystemTap. OProfile permet « juste » de se faire une idée de ce à quoi les CPUs passent leur temps de manière efficace tandis que DTrace et SystemTap permettent d'instrumenter à peu près tout et n'importe quoi de manière très fine.
En pratique, pour du profiling sur un truc CPU-bound, on va utiliser OProfile pour se faire une idée de la zone à instrumenter puis SystemTap pour observer plus précisement le code qui pose problème. Quand on perd son temps dans les I/O, OProfile est a peu près inutile. Par contre on peut utiliser blktrace et toujours SystemTap une fois qu'on sait ce qu'on veut instrumenter.
SystemTap est cependant bien plus qu'un outil de mesure de performance. L'exemple typique étant sigkill.stp qui permet de répondre à la question « Qui est-ce qui envoi un SIGKILL à mon process ? » http://sourceware.org/systemtap/examples/process/sigkill.stp
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
> SystemTap est un projet encore jeune (stable depuis qq. jours seulement),
> et rarement installé
Le passage à la version 1.0 ne marque pas le passage à une version stable. SystemTap est stable et utilisable et utilisé en production depuis un bon moment. Par contre, il est vrai qu'il manque encore pas mal de visibilité et les versions stables en 0.x n'ont sans doute pas aidé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Le navigateur ne se fie pas forcément au nom du fichier ou au Content-Type envoyé au niveau HTTP. Si foobar.jpg est en fait un document HTML, certains navigateurs vont l'interpréter tel quel plutôt que de le considérer comme un JPG invalide.
Une technique intéressante est d'avoir en parallèle la prod et un honeypot avec un IDS/IPS devant les deux. Si l'IPS/IDS détecte un truc qui cloche, il envoit le trafic vers le honeypot plutôt que la prod.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Après, si on veut bricoler, on peut utiliser SSH pour l'admin et netcat pour transférer les gros trucs sans chiffrer ni faire passer de mot de passe en clair.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
>> désactiver certaines fonctions si on en a pas besoin
>
> Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister
> quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des
> fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP,
> mais ça serait la meilleure solution.
C'est pas beaucoup mieux : il suffit qu'une des fonctions whitelistées ne soit pas blindée pour qu'on puisse faire ce qu'on veut dans le contexte de PHP. De plus, je ne vois pas beaucoup de cas d'utilisation de PHP dans lesquels il serait faisable d'auditer toutes les fonctions utilisées.
Il me semle plus efficace de s'appuyer sur les mécanismes de sécurité du système qui sont a priori bien mieux audités et donc fiables. Chaque contexte dans son espace d'adressage propre sans possibilité d'interagir avec le monde extérieur en dehors de certaines interfaces prédéfinies. Bon, après il y a un problème de performances potentiel mais il existe des compromis.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
> --- expose_php = off
> --- display_errors = off [1]
> - ne pas mettre le safe_mode à on, c'est une fausse sécurité
En quoi safe_mode=on est-il plus une fausse sécurité que expose_php=off ou display_errors=off ?
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
La première années c'était gratuit. Depuis, les prix font que monter on dirait. J'ai été en 2005 (1ère année) et 2007 et juste quelques heures en 2008. C'est sympa mais au final je trouve l'événement un peu plus commercial et moins amusant/intéressant chaque année. Aux dernières nouvelles, ça reste une bonne conférence technique de taille raisonnable trouve-je.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Désolé mais je crois que ton commentaire est un peu ambigü pour quelqu'un qui ne s'y connait pas : tu laisses penser que FUSE est la « bonne » manière de monter des systèmes de fichiers.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Depuis quelques mois, RHN utilise un CDN qui est censé faire que (presque tout) soit bien plus rapide qu'avant. Il y a eu quelques soucis avec RHN lors de la sortie de RHEL 5.4 / Satellite 5.3 mais pour autant que je sache, maintenant, c'est réglé. Il n'y a pas vraiment de moyen de choisir son mirroir manuellement. Si ta connexion permet de télécharger à plus de 300 ko/s, c'est censé suivre je pense.
Si tu as encore des problème de vitesse de téléchargement reproducibles avec RHN, tu peux ouvrir un ticket avec le support et on peut essayer de voir. Faudrait l'IP depuis laquelle tu télécharges, le résultat de "wget -S" sur un lien RHN pour un gros fichier, genre l'ISO du DVD de 5.4 par exemple, un (bout de) tcpdump du download et un sosreport du système depuis lequel tu télécharges tant qu'on y est.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: À rebours?
Posté par Krunch (site web personnel) . En réponse à la dépêche GDB 7.0 et le déverminage concurrentiel à rebours. Évalué à 5.
Par contre il me semble que ODB garde bien une trace de tout l'état du programme à chaque instruction (comme s'il était en mode « target record » en permanence donc).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: hein ?
Posté par Krunch (site web personnel) . En réponse à la dépêche GDB 7.0 et le déverminage concurrentiel à rebours. Évalué à 7.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: séparationj
Posté par Krunch (site web personnel) . En réponse au journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2. Évalué à 5.
> J'ai justement un petit disque dur super rapide, et un CPU super lent
> (1,6Ghz, c'est peu par rapport au DD qui peut fournir 110Mio/s).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Retour d'experience?
Posté par Krunch (site web personnel) . En réponse à la dépêche SystemTap 1.0 et Valgrind 3.5. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Espion qdisc et/ou Courbe temps-réel d'historique de variable kerne
Posté par Krunch (site web personnel) . En réponse au journal Espion qdisc et/ou Courbe temps-réel d'historique de variable kernel. Évalué à 10.
Malgré le manque de documentation et le peu d'explication, je pense avoir plus ou moins compris ce qu'est censé faire Clownix-Spy. Cependant, je m'interroge sur les choix techniques qui ont été réalisés.
Notamment, je crois comprendre que l'idée est de permettre l'observation de certains éléments interne au noyau. Cela nécessite cependant l'écriture de modules avec tous les risques et complications que cela comporte. Or, le projet SystemTap aborde déjà cette problèmatique et est relativement mature et intégré à plusieurs distributions. Ma question est donc : pourquoi ne pas se baser sur SystemTap ? Cela a-t-il été envisagé et rejeté ? Pourquoi ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: J'ai rien panéj
Posté par Krunch (site web personnel) . En réponse au journal Espion qdisc et/ou Courbe temps-réel d'historique de variable kernel. Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Bon c'est peut etre dans les details....
Posté par Krunch (site web personnel) . En réponse au message Aide pour débogger un module. Évalué à 4.
Si. Mais pas dans les logs. Si t'as pas la possibilité de monter une console série, tu peux essayer netconsole. Mais bon, après, k(g)db redevient peut-être plus pratique aussi.
> Pour les while, c'est juste pour être sûr que j'obtient le lock.
J'ai pas regardé le code mais ça pue assez bien ton truc là, que ça soit lié au problème ou non.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Bon c'est peut etre dans les details....
Posté par Krunch (site web personnel) . En réponse au message Aide pour débogger un module. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Retour d'experience?
Posté par Krunch (site web personnel) . En réponse à la dépêche SystemTap 1.0 et Valgrind 3.5. Évalué à 1.
De ce que j'en ai compris, DTrace a plus de fonctionnalités que SystemTap mais les développeurs stap travaillent à rattraper le retard. La version 1.0 est juste une continuité mais ne marque pas vraiment une avancée soudaine et importante.
OProfile n'est pas vraiment comparable à DTrace ou SystemTap. OProfile permet « juste » de se faire une idée de ce à quoi les CPUs passent leur temps de manière efficace tandis que DTrace et SystemTap permettent d'instrumenter à peu près tout et n'importe quoi de manière très fine.
En pratique, pour du profiling sur un truc CPU-bound, on va utiliser OProfile pour se faire une idée de la zone à instrumenter puis SystemTap pour observer plus précisement le code qui pose problème. Quand on perd son temps dans les I/O, OProfile est a peu près inutile. Par contre on peut utiliser blktrace et toujours SystemTap une fois qu'on sait ce qu'on veut instrumenter.
SystemTap est cependant bien plus qu'un outil de mesure de performance. L'exemple typique étant sigkill.stp qui permet de répondre à la question « Qui est-ce qui envoi un SIGKILL à mon process ? » http://sourceware.org/systemtap/examples/process/sigkill.stp
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 0 commentaire
Posté par Krunch (site web personnel) . En réponse à la dépêche SystemTap 1.0 et Valgrind 3.5. Évalué à 2.
> et rarement installé
Le passage à la version 1.0 ne marque pas le passage à une version stable. SystemTap est stable et utilisable et utilisé en production depuis un bon moment. Par contre, il est vrai qu'il manque encore pas mal de visibilité et les versions stables en 0.x n'ont sans doute pas aidé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Trolls velus
Posté par Krunch (site web personnel) . En réponse au journal bon anniversaire. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Répertoire d'upload
Posté par Krunch (site web personnel) . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: je suis pas convaincue
Posté par Krunch (site web personnel) . En réponse à la dépêche Sortie de Vala 0.7.6. Évalué à -1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Répertoire d'upload
Posté par Krunch (site web personnel) . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
Voir par exemple http://code.google.com/p/browsersec/wiki/Part2#Content_handl(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Investigation ?
Posté par Krunch (site web personnel) . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Accès FTP
Posté par Krunch (site web personnel) . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
Après, si on veut bricoler, on peut utiliser SSH pour l'admin et netcat pour transférer les gros trucs sans chiffrer ni faire passer de mot de passe en clair.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: D'autres trucs
Posté par Krunch (site web personnel) . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
>
> Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister
> quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des
> fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP,
> mais ça serait la meilleure solution.
C'est pas beaucoup mieux : il suffit qu'une des fonctions whitelistées ne soit pas blindée pour qu'on puisse faire ce qu'on veut dans le contexte de PHP. De plus, je ne vois pas beaucoup de cas d'utilisation de PHP dans lesquels il serait faisable d'auditer toutes les fonctions utilisées.
Il me semle plus efficace de s'appuyer sur les mécanismes de sécurité du système qui sont a priori bien mieux audités et donc fiables. Chaque contexte dans son espace d'adressage propre sans possibilité d'interagir avec le monde extérieur en dehors de certaines interfaces prédéfinies. Bon, après il y a un problème de performances potentiel mais il existe des compromis.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: D'autres trucs
Posté par Krunch (site web personnel) . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
> --- display_errors = off [1]
> - ne pas mettre le safe_mode à on, c'est une fausse sécurité
En quoi safe_mode=on est-il plus une fausse sécurité que expose_php=off ou display_errors=off ?
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Langue & ampleur de l'évènement ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Hack.lu - Version 2009. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Blobs et blobs
Posté par Krunch (site web personnel) . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: blagues
Posté par Krunch (site web personnel) . En réponse au journal Microsoft renoue avec ses fondamentaux. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Il n'empêche...
Posté par Krunch (site web personnel) . En réponse au journal Microsoft , Linux, BestBuy. Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Il n'empêche...
Posté par Krunch (site web personnel) . En réponse au journal Microsoft , Linux, BestBuy. Évalué à 3.
Est-ce qu'il y a seulement un client ssh fourni ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# blagues
Posté par Krunch (site web personnel) . En réponse au journal Microsoft renoue avec ses fondamentaux. Évalué à 7.
Non, qu'est-ce que je peux faire comme blague à mes collègues (qui sont tous sous Linux) ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: rhel et ppc
Posté par Krunch (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 5.4 : une rentrée pleine d'avant-premières technologiques. Évalué à 3.
Si tu as encore des problème de vitesse de téléchargement reproducibles avec RHN, tu peux ouvrir un ticket avec le support et on peut essayer de voir. Faudrait l'IP depuis laquelle tu télécharges, le résultat de "wget -S" sur un lien RHN pour un gros fichier, genre l'ISO du DVD de 5.4 par exemple, un (bout de) tcpdump du download et un sosreport du système depuis lequel tu télécharges tant qu'on y est.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.