Pour les signaux j'ai jamais dit non plus que c'etait impossible je dis juste que du code qui les utilise mal est tres tres courant...
>> plutot que l'infame methode utilisee par rotatelogs...
> C'est ton avis. J'aime bien logrotate.
Logrotate parait au premier abord peut etre une bonne idee, cependant il necessite du programmeur de faire 1 daemon capable de reouvrir ses logs, d'ecrire dans un repertoire, de gerer le timestamp et la ligne a ecrire.
Toutes les fonctions pour faire cela sont loin d'etre simple a utiliser, snprintf() par exemple (cf premier post).
Lorsque l'on code un daemon on aimerait s'occuper plus de ce qu'il doit faire et non pas de comment il va ecrire ce qu'il a fait.
On parle juste de temps ici, si notre daemon utilise les daemontools il n'a pas besoin de forker, pas besoin de d'ecrire 1 pid dans /var/run, pas besoin d'ouvrir un fichier de log.
Pour faire des logs corrects, il suffit juste de faire
write(1, log.s, log.len);
avec stralloc log.
Ainsi peu importe ce qu'il se passera note deamon n'auras _jamais_ le probleme du manque de plus de place sur le disque, ou de gerer un eventuel SIGHUP, ou de bien tout fermer en redamarrant completement.
C'est beaucoup plus simple, c'est exactement ce que la securite necessite: des choses simples.
Le paranoiaque pourra tout a fait tester la valeur de retour du write pour la comparer avec log.len, et agir en consequence.
Apres vos logs peuvent faire tout ce qu'il veulent, par exemple,
gzippedSQLthruSSL (j'utilise ca en production).
Et le processus de log tourne sous une autre Id.
Compromettez le, sachant qu'il ne souffre d'aucun buffer overflow, et qu'il tourne sous une id faible.
'rotatelogs' au final complique la vie du programmeur.
Les daemontools simplifie grandement la vie du programmeur, deplus le code est tellement simple et sure qu'il serait vraiment idiot de ne pas les utiliser.
Si tu prefere les methodes compliquees de programmation, qui prennent du temps a developper et ne sont pas sures au final c'est ton choix, mais personnellement utiliser des methodes sures, simples qui fonctionnent a tous les coups, je trouve cela _necessaire_ quand on parle de securite. On ne peut pas se permettre de faire tourner des choses dont on ne controle pas a 100% leurs comportements.
>> Le problème c'est d'utiliser tmpnam(NULL).
Le probleme ce n'est pas ca. Ce n'est pas non plus sa reentracy c'est que le random associe est completement pourri. Du man:
BUGS
Never use this function. Use mkstemp(3) instead.
De plus les codeurs ne pensent pas a faire un sous repertoire avant de passer le template a la fonction, lorsque l'on est root on doit proteger ce repertoire cree dans /tmp par un fchown. Pour le rendre inaccessible aux autres utilisateurs...
>> Parce qu'il faut réécrire un système pour loguer. Car il faut mettre en place un système pour communiquer avec le nouveau système pour loguer. Car par rapport à un système qui écrit directement dans un descripteur de fichier, c'est moins performant.
Sauf que les daemontools font ca pour toi directement sans rien devoir coder...
Il te fournissent meme le loggeur, et meme un loggeur capable d'ecrire dans syslog ...
Si tu veux pas prendre la peine d'aller voir les daemontools sache au moins que ca utilise la sortie standard et la sortie d'erreur, soit 0 et 1...
C'est une des raisons qui font qu'un daemon monitore ne doit pas se detacher... J'ai explique tout ca dans le premier post...
Les liens present dans mon premier post etaient la pour etayer mes dires.
Pour syslog... l'udp c'est pas la 'panacee'... Donc il faut le faire via un tunnel
SSH ou mieux SSL. Mais il faut quand meme coder le lecteur lisant depuis le named pipe pour ecrire dans le fd du tunnel. Si ce processus tombe alors c'est fini. Si tu ne sais pas pourquoi l'udp n'est pas la 'panacee' essaie de te documenter plus serieusement.
On ne parle pas de buffer overflow mais de race condition ce qui n'est pas du tout la meme chose...
Les race conditions apparaissent lorsque plusieurs fonctions utilisent elle meme
un const char * comme argument. Entre deux appels le fichier decrit par le parametre peut etre devenu un lien symbolique ou hard sur autrechose...
Il faut donc toujours travailler avec des fd.
Ce qui peut etre t'as trouble, et ce que je n'ai pas dit, mais ne me semblait pas necessaire, c'est que nous parlons des fonctions qui accedent au filesystem...
Je ne parle pas de _toutes_les fonctions prenant des const char * comme arguments. Je suis un lamer mais pas a ce point la.
[^] # Re: Et l'exemple qmail ?
Posté par forc3 . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 6.
>> plutot que l'infame methode utilisee par rotatelogs...
> C'est ton avis. J'aime bien logrotate.
Logrotate parait au premier abord peut etre une bonne idee, cependant il necessite du programmeur de faire 1 daemon capable de reouvrir ses logs, d'ecrire dans un repertoire, de gerer le timestamp et la ligne a ecrire.
Toutes les fonctions pour faire cela sont loin d'etre simple a utiliser, snprintf() par exemple (cf premier post).
Lorsque l'on code un daemon on aimerait s'occuper plus de ce qu'il doit faire et non pas de comment il va ecrire ce qu'il a fait.
On parle juste de temps ici, si notre daemon utilise les daemontools il n'a pas besoin de forker, pas besoin de d'ecrire 1 pid dans /var/run, pas besoin d'ouvrir un fichier de log.
Pour faire des logs corrects, il suffit juste de faire
write(1, log.s, log.len);
avec stralloc log.
Ainsi peu importe ce qu'il se passera note deamon n'auras _jamais_ le probleme du manque de plus de place sur le disque, ou de gerer un eventuel SIGHUP, ou de bien tout fermer en redamarrant completement.
C'est beaucoup plus simple, c'est exactement ce que la securite necessite: des choses simples.
Le paranoiaque pourra tout a fait tester la valeur de retour du write pour la comparer avec log.len, et agir en consequence.
Apres vos logs peuvent faire tout ce qu'il veulent, par exemple,
gzippedSQLthruSSL (j'utilise ca en production).
Et le processus de log tourne sous une autre Id.
Compromettez le, sachant qu'il ne souffre d'aucun buffer overflow, et qu'il tourne sous une id faible.
'rotatelogs' au final complique la vie du programmeur.
Les daemontools simplifie grandement la vie du programmeur, deplus le code est tellement simple et sure qu'il serait vraiment idiot de ne pas les utiliser.
Si tu prefere les methodes compliquees de programmation, qui prennent du temps a developper et ne sont pas sures au final c'est ton choix, mais personnellement utiliser des methodes sures, simples qui fonctionnent a tous les coups, je trouve cela _necessaire_ quand on parle de securite. On ne peut pas se permettre de faire tourner des choses dont on ne controle pas a 100% leurs comportements.
>> Le problème c'est d'utiliser tmpnam(NULL).
Le probleme ce n'est pas ca. Ce n'est pas non plus sa reentracy c'est que le random associe est completement pourri. Du man:
BUGS
Never use this function. Use mkstemp(3) instead.
De plus les codeurs ne pensent pas a faire un sous repertoire avant de passer le template a la fonction, lorsque l'on est root on doit proteger ce repertoire cree dans /tmp par un fchown. Pour le rendre inaccessible aux autres utilisateurs...
>> Parce qu'il faut réécrire un système pour loguer. Car il faut mettre en place un système pour communiquer avec le nouveau système pour loguer. Car par rapport à un système qui écrit directement dans un descripteur de fichier, c'est moins performant.
Sauf que les daemontools font ca pour toi directement sans rien devoir coder...
Il te fournissent meme le loggeur, et meme un loggeur capable d'ecrire dans syslog ...
Si tu veux pas prendre la peine d'aller voir les daemontools sache au moins que ca utilise la sortie standard et la sortie d'erreur, soit 0 et 1...
C'est une des raisons qui font qu'un daemon monitore ne doit pas se detacher... J'ai explique tout ca dans le premier post...
Les liens present dans mon premier post etaient la pour etayer mes dires.
Je te mets le lien direct:
http://cr.yp.to/daemontools.html(...)
Pour syslog... l'udp c'est pas la 'panacee'... Donc il faut le faire via un tunnel
SSH ou mieux SSL. Mais il faut quand meme coder le lecteur lisant depuis le named pipe pour ecrire dans le fd du tunnel. Si ce processus tombe alors c'est fini. Si tu ne sais pas pourquoi l'udp n'est pas la 'panacee' essaie de te documenter plus serieusement.
Retourne voir socklog de pape.
http://www.smarden.org/socklog/(...)
On ne parle pas de buffer overflow mais de race condition ce qui n'est pas du tout la meme chose...
Les race conditions apparaissent lorsque plusieurs fonctions utilisent elle meme
un const char * comme argument. Entre deux appels le fichier decrit par le parametre peut etre devenu un lien symbolique ou hard sur autrechose...
Il faut donc toujours travailler avec des fd.
Ce qui peut etre t'as trouble, et ce que je n'ai pas dit, mais ne me semblait pas necessaire, c'est que nous parlons des fonctions qui accedent au filesystem...
Je ne parle pas de _toutes_les fonctions prenant des const char * comme arguments. Je suis un lamer mais pas a ce point la.