Nous avons deux disques USB "My Passport" d'un To (modèles WDBACX0010BBL
et WDBACX0010BRD). J'ai une question sur le fonctionnement des buffers
disques.
Avec l'un ou l'autre disque, monté en ntfs-g3, je lance plusieurs fois la
commande suivante :
# time tar -C $repertoire_disque -c ./ > /dev/null
La 1ère fois, elle met environ 1'10" à se terminer
Un coup d'oeil sur le site de WDt me dit que le taux de transfert peut
atteindre 480Mo/s en USB-2, ce qui est le cas de mon système.
Déjà là, on dépasse la vitesse théorique de 50% !
Mais la 2ème fois, la commande prend 12", à la 3ème 5,2", puis 4.7", etc.
La comande du se comporte de la même manière ; 1'8" puis 3.7" en
enchaînant les appels avec un disque; mais 53" puis 13" avec l'autre.
Je n'ai que 2Go de RAM, il est impossible que les données des disques
soient bufferisées là. Quelqu'un pourrait me dire si cette évolution des
temps de transfert est normale et à quoi elle est dûe dans ce cas ?
Le 24 Nov 2011 08:24:40 GMT Nicolas George <nicolas$ a écrit :
YBM , dans le message <4ecdbc00$0$613$, a écrit : > Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Je suis content que quelqu'un soulève la question, parce que c'est un point sans rapport avec la discussion présente qu'il m'embêtait de laisser en suspens, pour la pollution dans les esprits qu'il propage.
Cette manie de coller du noexec,nodev,nosuid partout est typique des gens qui appliquent la sécurité comme un dogme, sans comprendre les mécanismes en jeu. N'importe qui qui a un tant soit peu étudié la question sait que ça conduit invariablement, comme le « plan vigipirate », à des mesures qui incommodent les usagers légitimes mais ne freinent pas du tout les attaquants.
Dans le cas de noexec, il existe de nombreuses méthodes : invoquer le chargeur dynamique directement, utiliser un langage interprété (NiKo en a parlé), on peut aussi produire une bibliothèque partagée et forcer un binaire normal du système à la charger.
Hum... ça peut quand même éviter à l'utilisateur de lancer un programme qu'il viendrait de télécharger en cliquant dessus, non ? Enfin sans doute que quand tu le télécharges et le stockes dans ton répertoire personnel ça lui attribue des droits du genre 664, mais si tu récupères une archive tar.gz et que tu la décompresses, tu te retrouve facilement avec un exécutable chez toi, non ? Avec un joli nom trompeur, et tu lances l'exécutable au lieu d'ouvrir un fichier que tu pensais moins dangereux.
Le 24 Nov 2011 08:24:40 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
YBM , dans le message <4ecdbc00$0$613$426a74cc@news.free.fr>, a
écrit :
> Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Je suis content que quelqu'un soulève la question, parce que c'est un
point sans rapport avec la discussion présente qu'il m'embêtait de
laisser en suspens, pour la pollution dans les esprits qu'il propage.
Cette manie de coller du noexec,nodev,nosuid partout est typique des
gens qui appliquent la sécurité comme un dogme, sans comprendre les
mécanismes en jeu. N'importe qui qui a un tant soit peu étudié la
question sait que ça conduit invariablement, comme le « plan
vigipirate », à des mesures qui incommodent les usagers légitimes
mais ne freinent pas du tout les attaquants.
Dans le cas de noexec, il existe de nombreuses méthodes : invoquer le
chargeur dynamique directement, utiliser un langage interprété (NiKo
en a parlé), on peut aussi produire une bibliothèque partagée et
forcer un binaire normal du système à la charger.
Hum... ça peut quand même éviter à l'utilisateur de lancer un programme
qu'il viendrait de télécharger en cliquant dessus, non ? Enfin sans
doute que quand tu le télécharges et le stockes dans ton répertoire
personnel ça lui attribue des droits du genre 664, mais si tu récupères
une archive tar.gz et que tu la décompresses, tu te retrouve facilement
avec un exécutable chez toi, non ? Avec un joli nom trompeur, et tu
lances l'exécutable au lieu d'ouvrir un fichier que tu pensais moins
dangereux.
Le 24 Nov 2011 08:24:40 GMT Nicolas George <nicolas$ a écrit :
YBM , dans le message <4ecdbc00$0$613$, a écrit : > Oui, que "noexec" est en réalité sans intérêt au niveau sécurité.
Je suis content que quelqu'un soulève la question, parce que c'est un point sans rapport avec la discussion présente qu'il m'embêtait de laisser en suspens, pour la pollution dans les esprits qu'il propage.
Cette manie de coller du noexec,nodev,nosuid partout est typique des gens qui appliquent la sécurité comme un dogme, sans comprendre les mécanismes en jeu. N'importe qui qui a un tant soit peu étudié la question sait que ça conduit invariablement, comme le « plan vigipirate », à des mesures qui incommodent les usagers légitimes mais ne freinent pas du tout les attaquants.
Dans le cas de noexec, il existe de nombreuses méthodes : invoquer le chargeur dynamique directement, utiliser un langage interprété (NiKo en a parlé), on peut aussi produire une bibliothèque partagée et forcer un binaire normal du système à la charger.
Hum... ça peut quand même éviter à l'utilisateur de lancer un programme qu'il viendrait de télécharger en cliquant dessus, non ? Enfin sans doute que quand tu le télécharges et le stockes dans ton répertoire personnel ça lui attribue des droits du genre 664, mais si tu récupères une archive tar.gz et que tu la décompresses, tu te retrouve facilement avec un exécutable chez toi, non ? Avec un joli nom trompeur, et tu lances l'exécutable au lieu d'ouvrir un fichier que tu pensais moins dangereux.
Nicolas George
Yliur , dans le message , a écrit :
Hum... ça peut quand même éviter à l'utilisateur de lancer un programme qu'il viendrait de télécharger en cliquant dessus, non ? Enfin sans doute que quand tu le télécharges et le stockes dans ton répertoire personnel ça lui attribue des droits du genre 664, mais si tu récupères une archive tar.gz et que tu la décompresses, tu te retrouve facilement avec un exécutable chez toi, non ? Avec un joli nom trompeur, et tu lances l'exécutable au lieu d'ouvrir un fichier que tu pensais moins dangereux.
L'option noexec ne peut pas faire la différence entre « je trouve un programme, je vérifie bien son origine, je le télécharge et je l'exécute » et « je trouve un programme, je le télécharge sans réfléchir, je l'exécute et je me fais avoir ».
Or le premier est un usage parfaitement légitime.
D'une manière générale, on peut chercher à protéger l'utilisateur contre sa propre bêtise, mais le moment où ça commence à gêner les usages légitimes est le moment où ça devient totalement contre-productif et où il faut arrêter.
D'autant que les utilisateurs sont souvent prêts à dépenser une énergie considérable pour quand même faire leurs bêtises, énergie qu'ils feraient mieux de consacrer à comprendre ce qu'ils font. On en a un très bon exemple dans ce thread avec ceux qui veulent à tout prix écrire dans /dev/shm.
Yliur , dans le message <20111124100515.0117343f@alcheringa>, a écrit :
Hum... ça peut quand même éviter à l'utilisateur de lancer un programme
qu'il viendrait de télécharger en cliquant dessus, non ? Enfin sans
doute que quand tu le télécharges et le stockes dans ton répertoire
personnel ça lui attribue des droits du genre 664, mais si tu récupères
une archive tar.gz et que tu la décompresses, tu te retrouve facilement
avec un exécutable chez toi, non ? Avec un joli nom trompeur, et tu
lances l'exécutable au lieu d'ouvrir un fichier que tu pensais moins
dangereux.
L'option noexec ne peut pas faire la différence entre « je trouve un
programme, je vérifie bien son origine, je le télécharge et je l'exécute »
et « je trouve un programme, je le télécharge sans réfléchir, je l'exécute
et je me fais avoir ».
Or le premier est un usage parfaitement légitime.
D'une manière générale, on peut chercher à protéger l'utilisateur contre sa
propre bêtise, mais le moment où ça commence à gêner les usages légitimes
est le moment où ça devient totalement contre-productif et où il faut
arrêter.
D'autant que les utilisateurs sont souvent prêts à dépenser une énergie
considérable pour quand même faire leurs bêtises, énergie qu'ils feraient
mieux de consacrer à comprendre ce qu'ils font. On en a un très bon exemple
dans ce thread avec ceux qui veulent à tout prix écrire dans /dev/shm.
Hum... ça peut quand même éviter à l'utilisateur de lancer un programme qu'il viendrait de télécharger en cliquant dessus, non ? Enfin sans doute que quand tu le télécharges et le stockes dans ton répertoire personnel ça lui attribue des droits du genre 664, mais si tu récupères une archive tar.gz et que tu la décompresses, tu te retrouve facilement avec un exécutable chez toi, non ? Avec un joli nom trompeur, et tu lances l'exécutable au lieu d'ouvrir un fichier que tu pensais moins dangereux.
L'option noexec ne peut pas faire la différence entre « je trouve un programme, je vérifie bien son origine, je le télécharge et je l'exécute » et « je trouve un programme, je le télécharge sans réfléchir, je l'exécute et je me fais avoir ».
Or le premier est un usage parfaitement légitime.
D'une manière générale, on peut chercher à protéger l'utilisateur contre sa propre bêtise, mais le moment où ça commence à gêner les usages légitimes est le moment où ça devient totalement contre-productif et où il faut arrêter.
D'autant que les utilisateurs sont souvent prêts à dépenser une énergie considérable pour quand même faire leurs bêtises, énergie qu'ils feraient mieux de consacrer à comprendre ce qu'ils font. On en a un très bon exemple dans ce thread avec ceux qui veulent à tout prix écrire dans /dev/shm.
Hugues
Ce cher Herve Autret a posté :
Hugues :
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
Là j'ai pas la casquette root ; j'essaie d'y penser quand c'est le cas.
Quoi, tu te loggues pas en root ? :)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Herve Autret <autret@lussinan.org> a posté :
Hugues :
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions
quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à
faire :-)
Là j'ai pas la casquette root ; j'essaie d'y penser quand c'est le cas.
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
Là j'ai pas la casquette root ; j'essaie d'y penser quand c'est le cas.
Quoi, tu te loggues pas en root ? :)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
Ce cher Nicolas George <nicolas$ a posté :
Le deuxième paragraphe est encore plus détaillé : il suggère d'utiliser tmpfs pour le répertoire /tmp, et c'est une excellente idée, que personnellement je suis depuis plus de huit ans
Peut-être pas depuis 8 ans pour mon cas, mais c'est effectivement ce que je fais sur toutes mes machines, sachant qu'on peut redimensionner à la demande cette partition si les 100Mo que j'ai alloués par défaut s'avèrent trop justes ;)
(en revanche, c'est une moins bonne idée pour /var/tmp, parce que /var/tmp est censé être plus pérenne que /tmp).
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de /var/tmp, mais en revanche, j'utilise un tmpfs pour /var/run et /var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Nicolas George <nicolas$george@salle-s.org> a posté :
Le deuxième paragraphe est encore plus détaillé : il suggère d'utiliser
tmpfs pour le répertoire /tmp, et c'est une excellente idée, que
personnellement je suis depuis plus de huit ans
Peut-être pas depuis 8 ans pour mon cas, mais c'est effectivement ce que
je fais sur toutes mes machines, sachant qu'on peut redimensionner à la
demande cette partition si les 100Mo que j'ai alloués par défaut
s'avèrent trop justes ;)
(en revanche, c'est une moins bonne idée pour /var/tmp, parce que
/var/tmp est censé être plus pérenne que /tmp).
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de
/var/tmp, mais en revanche, j'utilise un tmpfs pour /var/run et
/var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister
encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en
revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
Le deuxième paragraphe est encore plus détaillé : il suggère d'utiliser tmpfs pour le répertoire /tmp, et c'est une excellente idée, que personnellement je suis depuis plus de huit ans
Peut-être pas depuis 8 ans pour mon cas, mais c'est effectivement ce que je fais sur toutes mes machines, sachant qu'on peut redimensionner à la demande cette partition si les 100Mo que j'ai alloués par défaut s'avèrent trop justes ;)
(en revanche, c'est une moins bonne idée pour /var/tmp, parce que /var/tmp est censé être plus pérenne que /tmp).
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de /var/tmp, mais en revanche, j'utilise un tmpfs pour /var/run et /var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Nicolas George
Hugues , dans le message , a écrit :
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de /var/tmp,
/var/tmp est pour des données temporaires un peu plus pérennes que /tmp, en particulier qui sont censées survivre à un reboot.
mais en revanche, j'utilise un tmpfs pour /var/run et /var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
Ça ne m'a pas l'air absurde, surtout si le but est d'économiser le disque (SSD de premières générations). Il me semble que certaines distributions font de même au moins pour /var/run par défaut, d'ailleurs.
Hugues , dans le message <877h2p6byg.fsf@paranoid.sweethome>, a écrit :
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de
/var/tmp,
/var/tmp est pour des données temporaires un peu plus pérennes que /tmp, en
particulier qui sont censées survivre à un reboot.
mais en revanche, j'utilise un tmpfs pour /var/run et
/var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister
encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en
revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
Ça ne m'a pas l'air absurde, surtout si le but est d'économiser le disque
(SSD de premières générations). Il me semble que certaines distributions
font de même au moins pour /var/run par défaut, d'ailleurs.
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de /var/tmp,
/var/tmp est pour des données temporaires un peu plus pérennes que /tmp, en particulier qui sont censées survivre à un reboot.
mais en revanche, j'utilise un tmpfs pour /var/run et /var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
Ça ne m'a pas l'air absurde, surtout si le but est d'économiser le disque (SSD de premières générations). Il me semble que certaines distributions font de même au moins pour /var/run par défaut, d'ailleurs.
Hugues
Ce cher NiKo a posté :
2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm pour ses objets mémoire partagés, je ne vois pas dans le code le moindre avertissement signalant qu'il ne faut absolument pas qu'un utilisateur place des fichiers dans /dev/shm !
Peut être parce qu'on peut considérer, à partir du moment où on touche à la partie système, que les choses doivent être utilisées dans l'objectif prévu, et pas un autre ?
Par exemple, on peut faire un tas de choses dans /proc : écrire n'importe quoi dans les "fichiers" en mode write... D'ailleurs, en tant que root, tu peux faire "rm -rf /", pourtant tu ne vas pas le faire. Et pourtant, nulle part dans la doc de rm il n'est dit qu'il ne faut *PAS* le faire...
3) Sont vraiment nuls les développeurs du noyau et les développeurs GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à un utilisateur standard du système alors que Monsieur Nicolas George SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...
Non, il ne *SAIT* pas, il a juste compris (comme moi et d'autres personnes d'ailleurs) que ce répertoire a été créé dans un but donné. Et que ce but n'est pas, contrairement à ce que tu dis, que "tout le monde puisse y écrire n'importe quoi".
C'est très différent.
4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs ? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?
Oui, mais pas forcément.
5) Il serait temps que tu comprennes la philosophie Unix ... Le système n'est pas fait pour qu'un utilisateur ne puisse pas casser SA propre session, mais pour qu'un utilisateur ne puisse casser celle des AUTRES ainsi que le SYSTÈME complet.
Ça, je l'encadre :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher NiKo <NiKo@nomail.svp> a posté :
2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm
pour ses objets mémoire partagés, je ne vois pas dans le code le moindre
avertissement signalant qu'il ne faut absolument pas qu'un utilisateur
place des fichiers dans /dev/shm !
Peut être parce qu'on peut considérer, à partir du moment où on touche à
la partie système, que les choses doivent être utilisées dans l'objectif
prévu, et pas un autre ?
Par exemple, on peut faire un tas de choses dans /proc : écrire
n'importe quoi dans les "fichiers" en mode write...
D'ailleurs, en tant que root, tu peux faire "rm -rf /", pourtant tu ne
vas pas le faire. Et pourtant, nulle part dans la doc de rm il n'est dit
qu'il ne faut *PAS* le faire...
3) Sont vraiment nuls les développeurs du noyau et les développeurs
GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à
un utilisateur standard du système alors que Monsieur Nicolas George
SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...
Non, il ne *SAIT* pas, il a juste compris (comme moi et d'autres
personnes d'ailleurs) que ce répertoire a été créé dans un but donné. Et
que ce but n'est pas, contrairement à ce que tu dis, que "tout le monde
puisse y écrire n'importe quoi".
C'est très différent.
4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs
? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?
Oui, mais pas forcément.
5) Il serait temps que tu comprennes la philosophie Unix ... Le système
n'est pas fait pour qu'un utilisateur ne puisse pas casser SA propre
session, mais pour qu'un utilisateur ne puisse casser celle des AUTRES
ainsi que le SYSTÈME complet.
2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm pour ses objets mémoire partagés, je ne vois pas dans le code le moindre avertissement signalant qu'il ne faut absolument pas qu'un utilisateur place des fichiers dans /dev/shm !
Peut être parce qu'on peut considérer, à partir du moment où on touche à la partie système, que les choses doivent être utilisées dans l'objectif prévu, et pas un autre ?
Par exemple, on peut faire un tas de choses dans /proc : écrire n'importe quoi dans les "fichiers" en mode write... D'ailleurs, en tant que root, tu peux faire "rm -rf /", pourtant tu ne vas pas le faire. Et pourtant, nulle part dans la doc de rm il n'est dit qu'il ne faut *PAS* le faire...
3) Sont vraiment nuls les développeurs du noyau et les développeurs GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à un utilisateur standard du système alors que Monsieur Nicolas George SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...
Non, il ne *SAIT* pas, il a juste compris (comme moi et d'autres personnes d'ailleurs) que ce répertoire a été créé dans un but donné. Et que ce but n'est pas, contrairement à ce que tu dis, que "tout le monde puisse y écrire n'importe quoi".
C'est très différent.
4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs ? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?
Oui, mais pas forcément.
5) Il serait temps que tu comprennes la philosophie Unix ... Le système n'est pas fait pour qu'un utilisateur ne puisse pas casser SA propre session, mais pour qu'un utilisateur ne puisse casser celle des AUTRES ainsi que le SYSTÈME complet.
Ça, je l'encadre :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
Ce cher NiKo a posté :
Non, je m'attendais simplement à ce que tu me pointes une DOC qui stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans /dev/shm !
C'est la même que celle qui stipule que /dev est un dossier système dans lequel l'utilisateur lambda n'a rien à foutre... :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher NiKo <NiKo@nomail.svp> a posté :
Non, je m'attendais simplement à ce que tu me pointes une DOC qui
stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans
/dev/shm !
C'est la même que celle qui stipule que /dev est un dossier système dans
lequel l'utilisateur lambda n'a rien à foutre... :-)
Non, je m'attendais simplement à ce que tu me pointes une DOC qui stipulerais qu'il est idiot qu'un utilisateur crée des fichiers dans /dev/shm !
C'est la même que celle qui stipule que /dev est un dossier système dans lequel l'utilisateur lambda n'a rien à foutre... :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
Ce cher NiKo a posté :
Le 23/11/2011 16:18, Hugues a écrit :
Ce cher Herve Autret a posté :
Cette ressource n'est pas dissimulée (ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
Tiens, je te recopie un passage de mon message précédent, puisqu'il s'accorde parfaitement avec ta 'réflexion' :
Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root, ce qui change tout au problème énoncé ici, puisque 'normalement' lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du système.
Bon alors j'en ai une autre pour toi :
Ce n'est pas parce que tu as les droits d'écrire dans /tmp qu'il faut le remplir à ras bord.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
T'as déjà testé ?
Ce cher NiKo <NiKo@nomail.svp> a posté :
Le 23/11/2011 16:18, Hugues a écrit :
Ce cher Herve Autret <autret@lussinan.org> a posté :
Cette ressource n'est pas dissimulée (ce n'est pas comme si elle
s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de
raison de prendre des précautions quant à son emploi
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions
quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à
faire :-)
Tiens, je te recopie un passage de mon message précédent, puisqu'il
s'accorde parfaitement avec ta 'réflexion' :
Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root,
ce qui change tout au problème énoncé ici, puisque 'normalement'
lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du
système.
Bon alors j'en ai une autre pour toi :
Ce n'est pas parce que tu as les droits d'écrire dans /tmp qu'il faut le
remplir à ras bord.
Cette ressource n'est pas dissimulée (ce n'est pas comme si elle s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de raison de prendre des précautions quant à son emploi
Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à faire :-)
Tiens, je te recopie un passage de mon message précédent, puisqu'il s'accorde parfaitement avec ta 'réflexion' :
Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root, ce qui change tout au problème énoncé ici, puisque 'normalement' lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du système.
Bon alors j'en ai une autre pour toi :
Ce n'est pas parce que tu as les droits d'écrire dans /tmp qu'il faut le remplir à ras bord.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
T'as déjà testé ?
Hugues
Ce cher Nicolas George <nicolas$ a posté :
Hugues , dans le message , a écrit :
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de /var/tmp,
/var/tmp est pour des données temporaires un peu plus pérennes que /tmp, en particulier qui sont censées survivre à un reboot.
Mhm. Je vois ça. (le mien contient un "xfs_copy.log.XXX", c'est tout..) Bref :)
mais en revanche, j'utilise un tmpfs pour /var/run et /var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
Ça ne m'a pas l'air absurde, surtout si le but est d'économiser le disque (SSD de premières générations). Il me semble que certaines distributions font de même au moins pour /var/run par défaut, d'ailleurs.
Pour /var/run, ok, mais pour /var/lock ?
Le but est plutôt d'avoir un disque propre (ce n'est pas du SSD), et *surtout* d'éviter les blagues au reboot du genre "Oups, je ne peux pas lancer telle application, car /var/run/toto est présent" .. Bref, ça évite des soucis :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Nicolas George <nicolas$george@salle-s.org> a posté :
Hugues , dans le message <877h2p6byg.fsf@paranoid.sweethome>, a écrit :
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de
/var/tmp,
/var/tmp est pour des données temporaires un peu plus pérennes que /tmp, en
particulier qui sont censées survivre à un reboot.
Mhm. Je vois ça. (le mien contient un "xfs_copy.log.XXX", c'est tout..)
Bref :)
mais en revanche, j'utilise un tmpfs pour /var/run et
/var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister
encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en
revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
Ça ne m'a pas l'air absurde, surtout si le but est d'économiser le disque
(SSD de premières générations). Il me semble que certaines distributions
font de même au moins pour /var/run par défaut, d'ailleurs.
Pour /var/run, ok, mais pour /var/lock ?
Le but est plutôt d'avoir un disque propre (ce n'est pas du SSD), et
*surtout* d'éviter les blagues au reboot du genre "Oups, je ne peux pas
lancer telle application, car /var/run/toto est présent" ..
Bref, ça évite des soucis :-)
Là, par contre, je n'ai jamais vraiment fait gaffe à l'existence de /var/tmp,
/var/tmp est pour des données temporaires un peu plus pérennes que /tmp, en particulier qui sont censées survivre à un reboot.
Mhm. Je vois ça. (le mien contient un "xfs_copy.log.XXX", c'est tout..) Bref :)
mais en revanche, j'utilise un tmpfs pour /var/run et /var/lock, car àmha, au reboot, les process n'ont pas lieu d'exister encore.
Pour /var/run, il n'y a aucun problème à mon avis. Pour /var/lock en revanche, je pense que c'est plus discutable.. Tu en penses quoi ?
Ça ne m'a pas l'air absurde, surtout si le but est d'économiser le disque (SSD de premières générations). Il me semble que certaines distributions font de même au moins pour /var/run par défaut, d'ailleurs.
Pour /var/run, ok, mais pour /var/lock ?
Le but est plutôt d'avoir un disque propre (ce n'est pas du SSD), et *surtout* d'éviter les blagues au reboot du genre "Oups, je ne peux pas lancer telle application, car /var/run/toto est présent" .. Bref, ça évite des soucis :-)
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Yliur
Le 24 Nov 2011 09:16:07 GMT Nicolas George <nicolas$ a écrit :
Yliur , dans le message , a écrit : > Hum... ça peut quand même éviter à l'utilisateur de lancer un > programme qu'il viendrait de télécharger en cliquant dessus, non ? > Enfin sans doute que quand tu le télécharges et le stockes dans ton > répertoire personnel ça lui attribue des droits du genre 664, mais > si tu récupères une archive tar.gz et que tu la décompresses, tu te > retrouve facilement avec un exécutable chez toi, non ? Avec un joli > nom trompeur, et tu lances l'exécutable au lieu d'ouvrir un fichier > que tu pensais moins dangereux.
L'option noexec ne peut pas faire la différence entre « je trouve un programme, je vérifie bien son origine, je le télécharge et je l'exécute » et « je trouve un programme, je le télécharge sans réfléchir, je l'exécute et je me fais avoir ».
Non, mais il permet de faire : je trouve une archive, je la télécharge, je la décompresse, je clique sur un truc qui est un exécutable mais j'avais pas vu, ça ne me le lance pas. Et si je veux vraiment le lancer, j'utilise un répertoire dans lequel j'ai les droits de le faire (par exemple /tmp), la procédure habituelle n'étant pas de télécharger des programmes venus de nulle part comme ça (oui, ça dépend de ton utilisation bien sûr).
Or le premier est un usage parfaitement légitime.
D'une manière générale, on peut chercher à protéger l'utilisateur contre sa propre bêtise, mais le moment où ça commence à gêner les usages légitimes est le moment où ça devient totalement contre-productif et où il faut arrêter.
D'autant que les utilisateurs sont souvent prêts à dépenser une énergie considérable pour quand même faire leurs bêtises, énergie qu'ils feraient mieux de consacrer à comprendre ce qu'ils font. On en a un très bon exemple dans ce thread avec ceux qui veulent à tout prix écrire dans /dev/shm.
Il ne s'agit pas de protéger l'utilisateur contre son ignorance (là je suis d'accord que ce n'est pas la bonne solution), juste de lui éviter de faire une connerie par inattention.
La plupart des utilisateurs ne téléchargent pas des programmes à exécuter. Sauf quand c'est malencontreux.
Le 24 Nov 2011 09:16:07 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
Yliur , dans le message <20111124100515.0117343f@alcheringa>, a
écrit :
> Hum... ça peut quand même éviter à l'utilisateur de lancer un
> programme qu'il viendrait de télécharger en cliquant dessus, non ?
> Enfin sans doute que quand tu le télécharges et le stockes dans ton
> répertoire personnel ça lui attribue des droits du genre 664, mais
> si tu récupères une archive tar.gz et que tu la décompresses, tu te
> retrouve facilement avec un exécutable chez toi, non ? Avec un joli
> nom trompeur, et tu lances l'exécutable au lieu d'ouvrir un fichier
> que tu pensais moins dangereux.
L'option noexec ne peut pas faire la différence entre « je trouve un
programme, je vérifie bien son origine, je le télécharge et je
l'exécute » et « je trouve un programme, je le télécharge sans
réfléchir, je l'exécute et je me fais avoir ».
Non, mais il permet de faire : je trouve une archive, je la télécharge,
je la décompresse, je clique sur un truc qui est un exécutable mais
j'avais pas vu, ça ne me le lance pas. Et si je veux vraiment le
lancer, j'utilise un répertoire dans lequel j'ai les droits de le faire
(par exemple /tmp), la procédure habituelle n'étant pas de télécharger
des programmes venus de nulle part comme ça (oui, ça dépend de ton
utilisation bien sûr).
Or le premier est un usage parfaitement légitime.
D'une manière générale, on peut chercher à protéger l'utilisateur
contre sa propre bêtise, mais le moment où ça commence à gêner les
usages légitimes est le moment où ça devient totalement
contre-productif et où il faut arrêter.
D'autant que les utilisateurs sont souvent prêts à dépenser une
énergie considérable pour quand même faire leurs bêtises, énergie
qu'ils feraient mieux de consacrer à comprendre ce qu'ils font. On en
a un très bon exemple dans ce thread avec ceux qui veulent à tout
prix écrire dans /dev/shm.
Il ne s'agit pas de protéger l'utilisateur contre son ignorance (là je
suis d'accord que ce n'est pas la bonne solution), juste de lui éviter
de faire une connerie par inattention.
La plupart des utilisateurs ne téléchargent pas des programmes à
exécuter. Sauf quand c'est malencontreux.
Le 24 Nov 2011 09:16:07 GMT Nicolas George <nicolas$ a écrit :
Yliur , dans le message , a écrit : > Hum... ça peut quand même éviter à l'utilisateur de lancer un > programme qu'il viendrait de télécharger en cliquant dessus, non ? > Enfin sans doute que quand tu le télécharges et le stockes dans ton > répertoire personnel ça lui attribue des droits du genre 664, mais > si tu récupères une archive tar.gz et que tu la décompresses, tu te > retrouve facilement avec un exécutable chez toi, non ? Avec un joli > nom trompeur, et tu lances l'exécutable au lieu d'ouvrir un fichier > que tu pensais moins dangereux.
L'option noexec ne peut pas faire la différence entre « je trouve un programme, je vérifie bien son origine, je le télécharge et je l'exécute » et « je trouve un programme, je le télécharge sans réfléchir, je l'exécute et je me fais avoir ».
Non, mais il permet de faire : je trouve une archive, je la télécharge, je la décompresse, je clique sur un truc qui est un exécutable mais j'avais pas vu, ça ne me le lance pas. Et si je veux vraiment le lancer, j'utilise un répertoire dans lequel j'ai les droits de le faire (par exemple /tmp), la procédure habituelle n'étant pas de télécharger des programmes venus de nulle part comme ça (oui, ça dépend de ton utilisation bien sûr).
Or le premier est un usage parfaitement légitime.
D'une manière générale, on peut chercher à protéger l'utilisateur contre sa propre bêtise, mais le moment où ça commence à gêner les usages légitimes est le moment où ça devient totalement contre-productif et où il faut arrêter.
D'autant que les utilisateurs sont souvent prêts à dépenser une énergie considérable pour quand même faire leurs bêtises, énergie qu'ils feraient mieux de consacrer à comprendre ce qu'ils font. On en a un très bon exemple dans ce thread avec ceux qui veulent à tout prix écrire dans /dev/shm.
Il ne s'agit pas de protéger l'utilisateur contre son ignorance (là je suis d'accord que ce n'est pas la bonne solution), juste de lui éviter de faire une connerie par inattention.
La plupart des utilisateurs ne téléchargent pas des programmes à exécuter. Sauf quand c'est malencontreux.
