CoinKoin a écrit 698 commentaires

Grâce au patient travail de sape réalisé par des agents infiltrés français, la marine britannique a choisi un système d'exploitation bien connu pour son caractère "ouvert" (aux visites étrangères) pour équiper son parc informatique.

Pour plus d'informations, telnet secret.navy.gov.uk en port 23.

Dans ce cas précis, je crois que c'est la FSF (et ses avocats) qui sont les plus à même de réagir.

En ce qui concerne tes droits d'écriture, il est tout à faire normal que tu ne puisses pas écrire sur la partition w$, car par défaut, le module par défaut pour monter du NTFS est en lecture seule pour ne pas risquer de corrompre tes données (et mettre rw n'y changera rien, même étant root)

Oui, d'accord, mais actuellement, Linux peut écrire sur les partitions NTFS (grâce au travail de l'équipe de ReactOs : http://www.reactos.com/(...) ), mais ne peut pas créer de fichier. Il peut seulement les modifier, et ce sans risque de pertes de données.

Donc, pour écrire dans ta partition W$, il faut que tu te crées quelques fichiers vides, et ensuite que tu écrives dedans. Tu peux aussi modifier le contenu de fichiers existants, mais pas les supprimer.

Et si tu n'y parvenais toujours pas sur ta machine, à mon avis, ce serait une question de mise à jour du noyau.

Je pense, mais ce n'est qu'une opinion, que, si l'information contenue dans le courrier est pertinente, et qu'elle intéresse le public ("intéresser" au sens de "concerner"), cela doit pouvoir se justifier au nom de la liberté de la presse, Nathalie :) .

Attention, je sens que 007 est d'humeur trolleuse, ce soir...


http://linuxfr.org/~ehoebadoag/15204.html(...)

:-)

C'est exactement ce que je voulais montrer.

OK! On est donc entièrement d'accord, en fait.

Tu peux développer, pour OpenOffice?

A mon avis, à part ne pas tenter de créer de fichier temporaire ayant toujours le même nom dans /tmp, il ne devrait pas y avoir grand-chose à faire, non?

Et pour KDE? D'accord, il y a la gestion des périphériques (mais elle est plutôt mal faite, KDE ne comprend même pas ce qui se passe lorsqu'il n'a pas accès au son), l'histoire de /tmp, et peut-être de répertoires partagés comme pour samba (allez donc savoir tout ce que KDE gère :-) ).

Mais à part ça, je ne vois pas non plus les précautions à prendre...

(Ah oui, il faut que KDE fasse attention à la valeur de la variable DISPLAY. Ca non plus, ce n'est pas très bien fait. Mais ça relève plutôt du multi-écran que du multi-utilisateur, à mon avis, même si les deux sont liés.)

Bref ls tient bien compte du fait qu'il peut y avoir plusieurs utilisateurs ;-)

Perdu! :-)

C'est presque ça, mais ce n'est pas exactement ça...

Techniquement, ls fait un stat() sur les fichiers, et affiche leurs "filesystem user id" et "filesystem group id". Sous Linux, ces valeurs sont généralement égales aux uid et gid de l'utilisateur associé, mais ce n'est pas obligatoire.

S'il existe un utilisateur portant un uid égal au filesystem user id du fichier, ls affiche, pour simplifier la lecture, le nom de cet utilisateur, mais il peut arriver qu'il n'existe pas d'utilisateur portant cet uid, auquel cas ls affiche la valeur numérique du filesystem user id.

Bref, ls ne tient pas vraiment compte de ce qu'il peut exister plusieurs utilisateurs (sauf lorsqu'il tente la résolution du nom associé à un uid), il tient seulement compte d'une particularité du système de fichiers, et l'affiche.

Pour avoir plusieurs sessions en même temps :

echo startkde > ~/.xinitrc
xinit -- :1 &

echo startkde > ~/.xinitrc
xinit -- :2 &

etc...

(Oui, je sais, la ligne de commande n'est pas particulièrement conviviale.)

Désolé, je ne sais pas faire le même coup avec Gnome :( . Non,
echo gnome-session > ~/.xinitrc, ça ne suffit pas.

conclusion : ls a été pensé et programmé pour fonctionner en environnement multiutilisateur.

Tu parles...

Essaie donc de reprogrammer toi-même ls. C'est assez simple, et tu remarqueras tout de suite que, lorsque tu fais un opendir, tu peux recevoir les erreurs :

EACCES Permission denied.

EMFILE Too many file descriptors in use by process.

ENFILE Too many files are currently open in the system.

ENOENT Directory does not exist, or name is an empty
string.

ENOMEM Insufficient memory to complete the operation.

ENOTDIR
name is not a directory.

(tiré de man 3 opendir).

Le programmeur de ls, qui travaillait comme n'importe qui travaille, a tout simplement traité tous les cas d'erreur possibles, en faisant afficher un message pour chaque cas. Donc il s'est contenté de faire afficher un message traduisant le problème pour un être humain lorsqu'il recevait EACCES, et c'est tout.

Pas besoin d'aller chercher des histoires de conception pour le multiutilisateur, quand on programme à coup de manpages sous un UNIX, le multiutilisateur est géré sans même que l'on s'en rende compte.

$su
password:
#crontab -e
* * * * * chmod 666 /dev/sound/*
:wq
#exit
$ça y est!
bash: ça : command not found
$

:)

s/"pas chown"/"par chown" :)

- sous Linux, c'est plus simple, c'est la première session Gnome qui a le son, la 2ème n'a rien (je suppose que c'est lié au serveur son ALSA)


Non, c'est lié au fait que certains périphériques de /dev, comme /dev/sound/*, sont attribués (pas chown) au premier utilisateur qui se logge, et ce jusqu'à ce qu'il se délogge. Que le login ait lieu avec Gnome, KDE, WMaker ou même en mode texte.

Mais je ne sais pas quel processus est à l'origine de ce comportement, même si je soupçonne devfsd. Ce comportement m'a l'air assez mal documenté, je pense que ce sont les distributions qui le mettent elles-même en place.

Je ne connais pas FreeBSD, mais...

Si tu parviens à lire le système de fichiers en question avec un CD bootable (s/bootable/de démarrage :-) ), alors tu peux essayer de sauvegarder ton code sur disquette.

Ou même mieux, tu peux essayer de l'imprimer, ce qui te donnera une sécurité très solide.

Avec un peu de chance, seule une partie du disque, genre le secteur de boot, est cassée. Dans ce cas, tu peux aussi essayer d'employer une disquette de boot contenant grub, pour booter sur ton ancien noyau avec.

Bref, bonne chance!

Oups...

Alors comme ça, HD, ça ne veut pas dire Hurd Driver?

---->[]

Une précision, comme tu m'as l'air d'être un débutant (comme moi il n'y a pas si longtemps, en fait... :-) ) :

Ces commandes (wine toto.exe ou mono toto.exe) sont à taper dans un terminal. Il est possible de les taper dans les terminaux texte accessibles par ctrl-alt-F1 (ou F2 ou F3... ou F6), mais si ton programme essaie d'ouvrir une fenêtre, il n'y arrivera pas.

Il faut donc que tu prennes une fenêtre émulant un terminal, comme par exemple :

xterm,
Konsole (sous KDE),
Gnome-terminal (sous Gnome).

Ensuite, tu n'as qu'à taper ces commandes dedans.

Bonne journée!

CoinKoin

Si tu peux, échange les disques durs des deux portables, et le tour sera joué.

Cela etant dit, tout le monde sait que la raison pour laquelle on n'a toujours pas decouvert de petits hommes gris, c'est parce qu'ils sont deja parmis nous :).

Faux, c'est parce que nous sommes verts.

Oops, je me suis fait prendre, chef!

Je suppose que tu as gentiment gardé ta Mandrake allumée, et ta session root en marche...

Pour réparer /boot, à mon avis, il suffit de mettre à jour le noyau (et si urpmi était dans /sbin, pas grave, il te suffira d'aller en chercher un par ftp sur kernel.org).

Ensuite, si tu as Lilo, pas de problème, il n'aura pas été modifié par cette manip'. Si tu as Grub, ça m'a l'air plus délicat, mais tu pourras toujours booter en spécifiant la ligne de commande manuellement.

Pour sbin, c'est plus compliqué. Mon conseil, dans un premier temps, c'est de se créer une faille dans le compte root, genre un utilisateur supplémentaire dont l'uid est de 0, ce qui évite de réécrire "su" (pour ajouter l'utilisateur, trafique donc /etc/passwd et /etc/shadow), et de prendre le risque de ne plus rien pouvoir faire. Ensuite, il faut absolument faire cat /proc/1/exe > /sbin/init, pour récupérer un programme init viable.

A ce stade, le système est tout juste viable, et tu peux essayer de récupérer les sources des programmes de sbin chez MandrakeSoft pour les recompiler et les réinstaller.

Un dernier conseil : avant de faire ton prochain init 0 (ou 6), grave-toi une Knoppix, des fois qu'il resterait des programmes critiques non réinstallés...

Ne t'en fais pas, Lucas, je connais l'utilité de l'option --prefix :-).

Cela dit, s'il avait été malin, ton pirate, il aurait mis dans ton cher ./configure un truc du genre :

echo "première ligne de la backdoor">>.pirate.c
echo "...">>.pirate.c
echo "dernière ligne de la backdoor">>.pirate.c
echo "truc_pirate : \n\tgcc .pirate.c -o /etc/init.d/.backdoor && make all"">Makefile_2
echo "install : \tln -s /etc/rc3.d/S05bigbrother /etc/init.d/.backdoor\n\t
ln -s /etc/rc4.d/S05bigbrother /etc/init.d/.backdoor\n\t
ln -s /etc/rc5.d/S05bigbrother /etc/init.d/.backdoor">>Makefile_2
echo <lignes de l'ancien make install> >> Makefile_2
cat Makefile | grep -v install | grep -v <motif des lignes d'install> >> Makefile_2
rm Makefile && mv Makefile_2 Makefile


et là, la backdoor aurait été installée aussi sec par le root, lorsqu'il aurait fait make install...

(Finalement, je trouve que celui qui t'a dit que j'étais un peu pirate avait raison, Lucas ;-) ).

Donc, à mon avis, la protection apportée par le fait de faire ./configure et make en utilisateur, et make install en root, est totalement illusoire.

A+!

--
CoinKoin

Essaye de compiler en utilisateur dans /usr/local/src, et on verra si tu continues à dire ça.

/usr/local/bin, tu veux dire?

make your time.

O.K.

[root@localhost]# ./configure --name=time && make && make install

:-)

Alors, je suggère le téléchargement des dernières versions des logiciels en question (X.org et le pilote), suivi d'un rapport de bogue si ça ne marche toujours pas...

Moi, je ne vois plus rien d'autre à faire.

En attendant, il te reste les fb et la solution ci-dessous...

Je me réponds à moi-même...

De plus, ce jugement a été invalidé par la cour d'appel en 2003, donc, comme jurisprudence, on fait mieux :-) .

Ils ont été condamnés pour détournement du logo (déposé) de danone, et c'est tout. Donc cela n'a rien à voir avec le problème présent.