Et pB pG qui m'expliquait qu'il n'y avait rien à améliorer ici ...
Pire, il ne comprend pas qu'on puisse faire des recherches sur ça.
> Je connais plus d'un débutant qui a fait un programme qui stockait dans /tmp ou /home/debutant
Certe. J'ai moi même sur ma bécane quelques scripts avec les paths en dure.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Mais le non usage de $HOME se détecte très très vite.
Il faut être "réaliste".
Les problèmes de "/tmp" sont beaucoup plus importants car beaucoup plus difficile à trouver.
Biensûr on peut utiliser tmpfile() etc... Mais si le développeur ne connait pas ces fonctions son programme marchera sur plusieurs postes. La détection de l'erreur n'est pas "fulgurante" comme pour l'oublie de $HOME.
Enfin, les crakers adorent profiter de la mauvaise utilisation de /tmp.
Si le développeur ne connait pas tmpfile() et qu'il a besoin d'écrire des données temporaires il va peut être utiliser directement /tmp.
S'il ne prend pas quelques précautions de _sa propre initiative_ pour prendre en compte l'aspect multi-utilisateur, son programme ne sera pas multi-utilisateur compliant.
C'est LE point faible d'Unix.
Les autres trucs :
- IPC
- écriture dans /usr/share/no_where_and_ro
- non utilisation de $HOME
- etc
se détectent très très vites ou sont des erreurs de programmations (Par exemple une vérification du retour des appels système permet de localiser l'erreur).
Ces problèmes de sécurités sont en général fait par des programmes pas très multi-utilisateur compliant.
Tu vas dire que je suis en contradiction avec moi-même car je dis que les programmes n'ont pas à être multi-utilisateur compliant sous Unix !
Ben oui. Le problème de /tmp avec Unix est qu'il demande un effort de la part du développeur (ou ne le contraint pas) pour que le programme soit multi-utilisateur compliant.
Les dégâts se font très vite sentir et les problèmes de "/tmp" sont n°1 pour les trous de sécurité.
Voir cet article lwn : http://lwn.net/2000/1221/security.php3(...)
L'article est vieux et "presque faux" par endroit. Mais reste valable.
Unix a fait ici un erreur de conception assez grave et on peut se demander si ce problème sera corriger un jour (compatiblité oblige).
Il n'y a pas de fumé sans feu.
NB : je ne dis pas que c'est de la fautes des développeurs pour cacher une erreur de conception d'Unix...
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Et pB pG qui m'expliquait qu'il n'y avait rien à améliorer ici ...
Pire, il ne comprend pas qu'on puisse faire des recherches sur ça.
> Je connais plus d'un débutant qui a fait un programme qui stockait dans /tmp ou /home/debutant
Certe. J'ai moi même sur ma bécane quelques scripts avec les paths en dure.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Mais le non usage de $HOME se détecte très très vite.
Il faut être "réaliste".
Les problèmes de "/tmp" sont beaucoup plus importants car beaucoup plus difficile à trouver.
Biensûr on peut utiliser tmpfile() etc... Mais si le développeur ne connait pas ces fonctions son programme marchera sur plusieurs postes. La détection de l'erreur n'est pas "fulgurante" comme pour l'oublie de $HOME.
Enfin, les crakers adorent profiter de la mauvaise utilisation de /tmp.
Si le développeur ne connait pas tmpfile() et qu'il a besoin d'écrire des données temporaires il va peut être utiliser directement /tmp.
S'il ne prend pas quelques précautions de _sa propre initiative_ pour prendre en compte l'aspect multi-utilisateur, son programme ne sera pas multi-utilisateur compliant.
C'est LE point faible d'Unix.
Les autres trucs :
- IPC
- écriture dans /usr/share/no_where_and_ro
- non utilisation de $HOME
- etc
se détectent très très vites ou sont des erreurs de programmations (Par exemple une vérification du retour des appels système permet de localiser l'erreur).
Une recherche rapide des trous sécurités avec /tmp montre que c'est très courant (limité à lwn.net):
http://www.google.fr/search?hl=fr&ie=UTF-8&q=site%3Alwn.net(...)
Ces problèmes de sécurités sont en général fait par des programmes pas très multi-utilisateur compliant.
Tu vas dire que je suis en contradiction avec moi-même car je dis que les programmes n'ont pas à être multi-utilisateur compliant sous Unix !
Ben oui. Le problème de /tmp avec Unix est qu'il demande un effort de la part du développeur (ou ne le contraint pas) pour que le programme soit multi-utilisateur compliant.
Les dégâts se font très vite sentir et les problèmes de "/tmp" sont n°1 pour les trous de sécurité.
Voir cet article lwn :
http://lwn.net/2000/1221/security.php3(...)
L'article est vieux et "presque faux" par endroit. Mais reste valable.
Unix a fait ici un erreur de conception assez grave et on peut se demander si ce problème sera corriger un jour (compatiblité oblige).
Il n'y a pas de fumé sans feu.
NB : je ne dis pas que c'est de la fautes des développeurs pour cacher une erreur de conception d'Unix...