Oui, c'est un classique :

if [ -f /tmp/password ]; then
exec su "$@"
else
echo "Password:"
read pass
echo "$pass" > /tmp/password
echo "su: Authentication failure"
echo "Sorry."
exit 1
fi

L'utilisateur tente, se fait jetter et pense à une faute de frappe, réessaye et le deuxième coup marche.

[ Répondre ]

Si c'est l'utilisateur qui est malveillant, effectivement, ça ne change rien (il suffit que l'utilisateur se soit effectivement loggé en mode texte, et qu'il ai lancé un programme qui affiche le message de bienvenue suivi de login: puis password: et y'a qu'à attendre).

Si c'est un programme malveillant, je ne sais pas s'il a moyen de lancer un truc sur le stty (ou d'attraper le Ctrl-Alt-F1) sans intervention de l'utilisateur. Probablement possible, mais pas évident ...

[ Répondre ]

> une photo de Britney nue ne devrait pas pouvoir être executée sous Linux.

britney.jpg.exe, non, mais britney.jpg.desktop, malheureusement, si (enfin, sauf si ça a été corrigé dans les specs freedesktop depuis).

[ Répondre ]

Moi, j'attends toujours qu'on m'explique la différence entre un « virus » et un « vers ». Sachant que dans les deux cas, c'est un programme malveillant qui se propage contre la volonté de son utilisateur.

Et pour ceux qui prétendraient que les vers n'existent pas sous Linux, euh, bon, enfin voila quoi.

[ Répondre ]

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.

[ Répondre ]

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 ?

[ Répondre ]

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).

[ Répondre ]

> 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.

[ Répondre ]

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).

[ Répondre ]

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

[ Répondre ]

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.

[ Répondre ]

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 !)

[ Répondre ]

> 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 ?).

[ Répondre ]

> 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é.

[ Répondre ]

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 ;-).

[ Répondre ]

C'est faisable, pas juste a priori :

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

[ Répondre ]

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

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

> si je veux du fiable, j'utilise TCP

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

[ Répondre ]