Matthieu Moy a écrit 3251 commentaires

Tu tappes /bin/su
Le shell lit ça comme /bin/su
Le shell fait un execve("/bin/su", ...);

Mais qui est "le shell" ici ? Tu suppose que c'est bash, ou ton shell favori, mais qui te l'assure ? Qui a lancé ce shell ? L'icône « terminal » dans une barre des tâches KDE/Gnome/autre ? Tu es _sur_ que ça lance bien un bash ? L'attaquant peut tout à fait aller modifier la config de ton environnement de bureau pour lancer un shell bidon à la place du tiens (ou alors faire un "exec shell-bidon" dans ton ~/.profile), ou comme dit plus bas faire un coup de LD_PRELOAD pour redéfinir execvp par exemple. C'est pas trivial à faire, mais pas impossible non plus.

Et d'ailleurs, une fois /bin/su lancé, même si c'est le bon, y a-t-il un keylogger sur ta machine ?

À partir du moment où ton compte est compromis, et si l'attaquant est un peu dégourdi, tu ne peux plus compter sur rien dans ce que tu fais à partir de ce compte.

Sur une machine perso, sur laquelle l'utilisateur tape le mot de passe root de temps en temps, entre le moment où le compte utilisateur est compromis et le moment où le système est compromis, ce n'est qu'une question de temps et de persévérance.

Et même s'il avait donné le chemin complet, qui lui aurait garanti que le shell dans lequel il le tapait allait lancer le vrai su ?

Il me semble que ça existe déjà sur des ultra-portables, mais sans changement « à chaud » (1 arm qui consomme rien avec un système ultra-minimal qui boot vite et un i386 quand on veut _vraiment_ se servir de la bête).

> Comportement complexe = plus de bugs

Euh, si c'est ça l'argument, ça prêche en faveur de l'arret à la première erreur, non ? La récupération d'erreur dans les compilateurs, c'est une question pas évident à résoudre correctement (et GCC est particulièrement mauvais sur ce point), la solution triviale, c'est de s'arrêter de suite.

Compiler plusieurs fichiers sans s'arrêter, ça n'a rien à voir avec la récupération d'erreurs de GCC. C'est make (ou équivalent, enfin le truc qui appelle GCC) qui s'occupe de ça (avec l'option -k).

Euh, en quoi ça répond au problème, ça ?

Est-ce encore vrai avec la 3.0 ? J'ai pas essayé, mais d'après le screenshot ici

http://blogs.sun.com/GullFOSS/entry/error_bars_from_cell_ran(...)

il y a l'air d'y avoir tout ça.

Un appercu de même style que le journal, mais en anglais et en images :

http://www.oooninja.com/2008/03/openofficeorg-30-new-feature(...)

(c'est vrai que globalement, ma réaction sur la plupart des points est plutôt "enfin" que "oh, superbe inovation", mais y'a quand même du bon dans cette version !)

> La régression linéaire dans un tableur, si il faut attendre la version 3.0 pour la voir apparaître, je trouve ça un peu bizarre.

Si j'ai bien compris, c'est un _solveur_ linéaire (simplex & cie ?).

> En ce qui concerne les performances, le problème principal que je vois à bzr,
> c'est le temps de lancement de python,

Malheureusement, sur des projets avec un historique un peu long, ce n'est pas le seul. Voir par exemple :

https://lists.ubuntu.com/archives/bazaar/2008q1/039273.html

Sur le repository d'Emacs, un "git log" complet met 5 secondes, alors que "bzr log" sur les 10 dernières révisions prends déjà plus de 2 minutes. Idem pour commiter : en général, "bzr status" est rapide, mais "bzr commit" est affreusement lent même en local. "git commit" est quasi-instantané sur tous les projets sur lesquels je l'ai essayé.

Dans la série des Windowsiens qui se foutent de la gueule de Linux, je trouve celui là assez imbattable :

Are you saying that this linux can run on a computer without windows underneath it, at all ? As in, without a boot disk, without any drivers, and without any services ?

That sounds preposterous to me.

If it were true (and I doubt it), then companies would be selling computers without a windows. [...]

Lire la suite absoluement :

http://talkback.zdnet.com/5208-12355-0.html?forumID=1&th(...)

Si c'est un fake, il est très bien fait, et sinon, euh, no comment ;-).

C'est faisable, pas juste a priori :

http://linuxfr.org/~palm123/26212.html

Sinon, moi, ion3 + clavier dvorak, c'est aussi efficace que du chiffrement et des mots de passes ;-).

Puisque tu as l'air de connaître un peu le sujet, est que tu serais me dire si au niveau performance cela est équivalent ? Bien sûr c'est fortement dépendant de comment on code la gestion...

Je connais pas particulièrement ;-).

Niveau performance, oui, ça dépends comment tu gère les pertes de paquets. Pour NFS, j'ai souvenir d'avoir lu dans le man que TCP était plutôt plus rapide vu que la ré-émisson en cas de perte se faisait au niveau paquet alors qu'en UDP c'était au niveau requete, mais j'ai un man différent sous la main qui ne parle pas de ça, et qui dit qu'UDP est le défaut, il doit y avoir une raison !

Sinon, un protocole non-fiable peut aussi être utilisé dans les cas où tu sais traiter les paquets dans le désordre : un paquet perdu ne t'empêche pas de continuer à traiter ce qui arrive au fur et à mesure et attendant la ré-émission.

TCP est _un_ moyen d'avoir une connexion fiable, mais tu peux tout à fait ajouter l'équivalent dans la couche applicative. L'intérêt étant que l'application peut savoir mieux que le protocole quoi faire quand on perd un paquet, mais par contre, ça fait plus de boulot pour l'applie.

Par exemple, NFS peut tourner sur du UDP, je ne retrouve pas précisément, mais je suis 99% sur qu'il y a un méchanisme de checksum comparable à celui de TCP, et « man nfs » par le méchanisme de ré-émisson de requetes NFS quand elles sont perdues.

> si je veux du fiable, j'utilise TCP

ça, il ne faudra pas lui dire trop fort, à ton prof de réseau.

Si j'ai bien compris, sa défense était en partie basée sur le fait qu'il pensais que sa femme était toujours vivante, probablement partie en Russie. Donc, ce qui est flagrant, c'est qu'il a menti, et qu'il a basé sa défense sur un mensonge. En soi, ça ne prouve pas que ce soit lui qui a tué, mais du point de vue du tribunal, ça confirme quand même qu'ils ont eu raison de le condamner.

Euh, on doit pas parler du même RMS alors.

Parce que

http://www.gnu.org/philosophy/linux-gnu-freedom.html
http://www.fsf.org/blogs/rms/can-we-rescue-olpc-from-windows

Ça m'a tout l'air de dire le contraire quand même ...

Euh, tu le fais exprès ou quoi ? Relis bien le morceau que tu cites toi-même (le morceau, pas ta traduction), il dit le contraire de ce que tu dis.

À part ça, ce que tu cites est un texte « philosophique » et non la licence. Quand j'ai dit « relis la GPL », je voulais vraiment dire « la GPL », par exemple ce bout là (point 3b) :


Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, [...]


ou en GPL v3 :


for a price no more than your reasonable cost of physically performing this conveying of source,

Non, relis la GPL.

> La licence est claire, libre à vous de ne pas utiliser ce code.

Euh, c'est quoi la différence avec les licences propriétaires du coup ?

Windows aussi, tu es libre de ne pas l'utiliser ...

que rsync copie d'une source vers une destination, et ne fait pas de fusion bi-directionnelle, comme le fait par exemple unison (ou alors carrément des gestionnaires de versions, mais c'est une autre histoire).

Oui l'intérêt semble maigre, surtout vu les exemples d'applications « Linux » donnés : Firefox, OpenOffice ... réputés pour avoir une version native meilleure que la version Linux !

> Pire, il ne semble même pas donner l'impression de se renseigner un minimum sur ce qu'il avance.

Malheureusement, c'est même un fait avéré.

Pour une raison que j'ignore, Stallman s'interdit de surfer sur le Web, sauf sur les sites gnu.org et fsf.org. Donc, quand il dit « OpenBSD contient du non-libre », il ne faut pas lire « je suis allé sur openbsd.org et j'ai vu que ... », mais bien « il parait que ... ».

J'ai une fois prononcé les mots « Red Hat » à porté de l'oreille de Stallman, il s'est mis à crier « Red Hat contains non-free software ». J'ai demandé (en toute bonne foi) lesquels, il a répondu qu'il ne savait pas, mais que c'était sûr, puisqu'on lui avait dit qu'il y en avait.

oui mais non : d(sin(7x))/dx = 7cos(x).

Mais t'as de la chance, le coefficient 7 part dans la division par zéro de toutes façons.