Obsidian a écrit 5313 commentaires

Si tu fais un argv+(i+1), tu ne transmets pas un argument à la fois mais la fin du tableau, avec chaque fois un élément en moins. Essaie plutôt:


/* Programme qui lance plein d'applications */

#include <unistd.h>
#include <stdio.h>
#include <errno.h>

int main (int argc,char **argv)
{
if (argc>1)
{
int i;
int r;
char * param [3];

param [0] = argv[0];
param [2] = NULL;

for (i=1;i<argc;i++)
{
r=fork();

if (!r)
{
param [1] = argv [i];
if (execve("./programme",param,environ)<0) perror ("Erreur sur execve");
}
else if (r<0) perror ("erreur sur fork()");
}
}
else fprintf (stderr,"Merci de spécifier des arguments");

return 0;
}

Cela vient probablement du argv+1 qui doit être transmis tel quel au nouveau programme. le "+1" ici permet de shifter tous les arguments vers la gauche et d'éjecter le nom du fichier originel.

Essaie d'utiliser juste "argv" ou alors de lancer le programme tel quel mais en passant un argument dans ta ligne de commande (qui correspondrait par exemple au nom que tu voudrais donner à l'autre programme :-) ).

"Bad adress" = EFAULT = Une segfault à l'appel de ta fonction = un pointeur fou.

Lis la man page de execve, il parle de l'argument "fichier", mais à mon avis c'est le pointeur env qui est initialisé à zéro qui ne lui plaît pas. Suis mon exemple ci-dessous ou celui de Christophe GRAND, et dis-nous si ça marche.

Je crois qu'il y a belle lurette que les occupants de ce canal ont cessé d'essayer d'avoir l'air malin.

char **env = 0;
int result = execve("monpremier programme", argv + 1, env);


#include <unistd.h>
int result = execve("monpremier programme", argv + 1, environ);

Comme ça, tu transmets les variables d'environnement.
(void man environ).

export PATH=$PATH:.

peut-être ?

Mais le plus propre serait d'ajouter "./" au début du nom de ton fichier.

Sale affaire, d'autant plus grave que Mandrake n'y est pour rien !

Mais l'éducation des gens en informatique et l'état des monopoles actuels font que c'est Mandrake - qui a connu des jours meilleurs - qui doit faire les frais d'une erreur de conception sur une seule marque de lecteur.

Si l'erreur se produisait à l'installation de la nouvelle mouture de Windows, Microsoft corrigerait probablement ses masters aussi, mais je ne pense pas qu'il y aurait rappel. Et dans tout les cas (puisque ce serait largement relayé dans la presse spécialisée), l'organisme mis en cause serait clairement LG, et personne d'autre.

Probablement mais, tu dois le savoir très bien d'ailleurs, David N. Cutler, en charge du projet VMS chez Digital, a été débauché par Microsoft pour développer WNT, et la rumeur est née de là. D'ailleurs l'une des principales couches de ce dernier système est HAL (Hardware Abstraction Layer) qui isole le système des spécificités techniques de chaque machine ...

C'est sûr qu'avec de tels exemples, ils ne pouvaient pas produire un OS fiable ... :-)

La vache, un PS qui freeze ta session ? C'est violent ...
Tes process sont en state "D", je suppose ? Il n'y a pas beaucoup de doc la-dessus, mais cela m'est déjà arrivé avec des noyaux 2.2.x et 2.4.x . Spécialement avec Netscape.

Un admin m'a dit un jour que cela arrivait souvent sur les accès aux fichiers, et qu'il fallait attendre que le kernel finisse ce qu'il doit faire, donc, je suppose que cela arrive lorsque le kernel fait une opération « atomique » sur ton processus mais qu'il attend quand même quelque chose de l'extérieur. Cela arrive typiquement avec les I/O. Tu dois pouvoir prendre un "D" lorsque tu tues un processus qui avait ouvert des fichiers au travers d'un NFS, par exemple, et que celui-ci n'est plus accessible. Le kernel va essayer de nettoyer tout ce qui a été laissé en plan par le processus, notament fermer les fichiers, mais cette opération est l'initiative du noyau, et pas celle du processus, censé être mort, et qui ne peut donc plus recevoir aucun code de retour. Si le NFS est down, le VFS va attendre ad vitam aeternam la réponse des couches de plus bas niveau (en tout cas, jusqu'à un timeout du VFS), ce qui veut dire que c'est le kernel lui-même qui ne rend plus la main. Cela doit aussi arriver sur des périphériques lents alors qu'ils ne sont pas censés l'être (lecture sur un CD rayé, par exemple). Je suppose qu'il doit également y avoir moyen de provoquer des deadlocks entre des tubes ou des sockets.

Bon tout cela est très hypothétique. C'est peu documenté car cela ne devrait pas arriver. Je m'en vais potasser les sources du noyau pour voir si je trouve plus d'infos.

En tout cas, la moralité de l'histoire est que lorsque cela arrive, la première chose à faire est d'essayer de trouver ce qui bloque ton processus, et le premier endroit où regarder est /proc/fd, qui contient les descripteurs de tous les fichiers ouverts par le processus.

Bon courage.

Hmm, j'ai pas vu le film mais vu les restrictions gouvernementales actuelles concernant la durée du chômage, mais également les aides en tous genres accordées notament aux personnes en stage, je ne pense pas que ce soit encore d'actualité, malheureusement.

En dehors de çà, j'ai toujours adhéré à l'idée de ne pas perdre sa vie à la gagner, d'autant que bien souvent, le premier job que l'on récupère après une carrière honorable fait perdre ses droits au chômage et rapporte moins que les allocations perçues avant, mais malgré cela, je ne pense pas qu'inciter les gens à ne pas travailler soit une bonne idée.

Si justement on peut se permettre un temps mort entre deux emplois pour se retrouver un peu, c'est parce que l'on a un système qui permet de le faire et que beaucoup de gens nous envient. En abuser reviendrait à le saborder, et là, c'est tout le monde à la rue.

At this point, please do not install Mandrake Linux 9.2 on any computer containing a LG-based CD-ROM drive or it will damage your CD-ROM drive.

Ce n'est pas les CD-ROM d'installation que Mandrake/Linux va tuer, c'est le lecteur lui-même ! Pourtant je ne leur jette pas la pierre (d'ailleurs j'utilise moi-même Mandrake 9.1).

a) Comment se fait-il qu'en 2003, on trouve encore du matériel que l'on puisse griller logiciellement ?
b) Comment se fait-il qu'en 2003, on trouve encore des fabricants qui ne sachent pas ce qu'est Linux ?

Pour a), imaginez un peu que quelqu'un répande un virus Windows qui exploite cette faiblesse. La publicité que cela engendrerait pousserait probablement le fabricant à améliorer ses produits.

Pour b), c'est déjà limite acceptable pour un éditeur de logiciel, qui s'appuie sur le système d'exploitation. Cela ne l'est pas du tout de la part d'un fabricant de pièces détachées comme un lecteur de CD qui devrait tout au plus se baser sur le standard ATA pour les lecteurs IDE.

Sans réponse valable à ces deux questions, je considère que ce fabricant est à exterminer de la même façon que les trolls régulièrement tapis dans les coulisses de DLFP.

ASM roulaize !

Rien de tel que de découvrir comment fonctionne réellement sa bécane.
Sinon vient le C, puis le Bash, puis le C++ et enfin un peu de Basic 512 :-)

Voila pour mes préférences.

Et moi aussi !
Rien que pour cela, ça mérite un [+] :-)

Bon, tout cela est bien beau, mais pourquoi n'installes-tu pas un bootloader, comme tout le monde ?

Un bon petit LILO ou GRUB des familles, un menu de démarrage, une temporisation d'environ 10 secondes, et tu ne t'emmerde plus à faire mumuse avec fdisk ou que sais-je ...

Okay, le raccourci était peut-être un peu trop serré, mais bon.

Ce que je veux dire, c'est que je n'adhère pas vraiment au projet de loi qui « criminalise » le fait de fureter sur le réseau. Pour moi, il s'agit d'une utilisation normale d'un ordinateur et d'un réseau et faire un scan sauvage ne devrait pas pouvoir t'envoyer en prison.

Si ton objectif est de couler une compagnie ou de récupérer des données confidentielles, c'est cet acte là qu'il faut condamner, et pas le fait d'utiliser un ordinateur pour arriver à ses fins.

Je vais aussi prendre un autre cas: Le défaçage de sites web. Mon opinion (et je suis bien conscient que tout le monde ne la partage pas, loin de là) est qu'un tel site est par définition rendu public. A ce niveau, défacer un site revient exactement à aller tracer une croix noire sur une affiche 4x3 dans la rue (pour reprendre un fait divers récent). Cela n'a rien à voir avec du cyberterrorisme.

Je pense enfin que le nombre de personnes réellement mal intentionnées est bien faible comparé à celui de tous les cyberdélinquants en puissance. Pourtant, on a voté contre ceux-ci des lois excessives, je crois que tout est là, qui font qu'un des script-kiddies dont tu parles et qui aurait envie ne serait-ce que de savoir sur quelle machine fonctionne un site par exemple risque la prison (alors que son intention n'a rien de préjudiciable pour quiquonque en elle-même).

Il y a quelqu'un sur ce site qui a très justement fait remarquer qu' « il va devenir plus dangereux de manipuler un clavier qu'une arme à feu ».

Tu déclares en outre « [...] et qui ne sont pas conscients de la mauvaise configuration de leurs bécanes, ou des failles de sécurité des services que celle ci propose au grand ternet. ». Je crois que c'est là même l'objectif de l'auteur de ce journal. Les utilisateurs dont parles ne risquent pas de prendre conscience de si tôt de ces problèmes, puisqu'il est pratiquement interdit, désormais, de faire les démarches pour obtenir ces informations.

Exact ! Il y a longtemps que la police a réglé le problème. Pourquoi se faire suer à sécuriser le parc informatique français alors que c'est si simple d'interdire aux gens de faire des audits ...

C'est pas encore demain que l'on pourra travailler dans des conditions normales :-\

Mouais, c'est étrange tout de même ...

Knoppix a parfois des comportements pour le moins inattendus au niveau de sa ligne de commande, mais dans ton cas, tu as réclamé la sauvegarde de ta dernière partition primaire dans un fichier se trouvant dans le répertoire /dev/hda5, lequel n'existe pas puisque ce chemin correspond au nom d'un fichier spécial. La commande aurait du échouer.

D'autre part, si tu avais fait une copie de /dev/hda4 vers /dev/hda5, tu aurais écrasé le secteur de boot de ta partition Linux, ce qui n'aurait probablement eu aucune conséquence. Si tu avais écrasé /dev/hda à la place de /dev/hda5, tu aurais écrasé ton MBR + la table de tes partitions ! Pas glop, mais il aurait été aisé de les reconstruire (à condition de savoir sur quels cylindres se trouve tes partitions). Peu de gens le savent, d'ailleurs. La plupart des gens croient que MBR écrasé = disque dur formatté, alors que c'est nettement moins grave que de perdre sa FAT par exemple.

C'est çà qui est étonnant: En faisant ls /dev/hda5 (et pas /mnt/hda5), tu as vu ton fichier ! Cela veut dire que Knoppix a écrasé le fichier spécial, a créé un répertoire à la place - dans son RAMDISK - et y a mis ton fichier.

Tu as fini par découvrir qu'il s'agissait d'un double flag de boot, tant mieux, mais visiblement ta manip n'a rien à voir dans l'histoire ...

« Il y a deux types d'administrateurs Unix: ceux qui ont déjà fait une grosse connerie en temps que root et ceux qui vont bientôt la faire ». Le vieil adage se vérifie régulièrement :-)

electionmethods.org, dont le vote Condorcet:

http://electionmethods.org/fr/CondorcetEx.htm(...)

Effectivement intercepté dans un des journaux de linuxfr.org.

Allez, pas de jaloux, un point Godwin pour tout le monde ! :-)

Ouais, enfin cette killer-feature existait sous DaCode, et c'est vrai qu'elle manquait beaucoup. Un petit target et tout rentre dans l'ordre.

A l'époque, j'vais un 8086 et le bouton « Turbo » se trouvait juste à coté ... Plusieurs fois, j'ai fait l'erreur de vouloir l'enclencher / le déclencher à l'aveugle en gardant les yeux sur l'écran. Cela apprend la vie ! :-)

Enfin un poste interressant ! :-)
Merci.

Soit l'uptime moyen constaté d'un OpenBSD.

Ben, à la limite, si la puce en question se résume à une bascule bistable, il doit bien y avoir moyen de la faire commuter à 25Ghz. Tout est question d'interprétation ...

Hormis cela, même si cela existait, le débit du bus PCI greverait les performances à lui seul.