Chez moi, le seul fichier qui appartient au groupe video est le fichier /dev/agpart (je suis sous LFS 6.1). Quel est le user/group de ce fichier chez toi ?
Alors normalement, *dm (wdm, xdm, gdm ou kdm) sont démarrés par le processus init au niveau 5. Pour ne pas lancer X automatiquement, tu as deux choix:
ou passer le paramètre init 3 au boot du kernel sous Grub. (Normalement Grub te permets de le faire en appuyant sur e au boot). Chez moi la commande est:
kernel /boot/vmlinuz ro root=/dev/hda1
tu la modifies pour rajouter init 3. Moi je ferais:
kernel /boot/vmlinuz ro root=/dev/hda1 init 3
Soit effectivement tu bootes sur un LiveCD, tu montes ta partition root et tu édites le fichier /mnt/broken_system/etc/inittab
Tu repères la ligne où il y a
id:5:initdefault:
et tu la remplaces par
id:3:initdefault:
En ce qui me concerne, je passe toujours le niveau d'init par défaut à 3 avant toute manipulation de X pour éviter ce problème.
Au début je me suis dit, dommage comme nom ça passe vraiment pas en français.
Mais en fait le développeur est un francophone qui assume complètement (voir le logo).
> seulement lors de mes tests je n'obtiens les résultats escomptés:
Quels résultats attends-tu ? Est-ce que ton utilisateur arrive à se loguer ? AMHA par la suite, il n'y a aucune chance qu'un client Microsoft quelconque (Outlook, IE, l'explorateur de fichiers, client SQL Server, ...) puisse utiliser le ticket obtenu pour faire quoi que ce soit. Pour cela, je suis à peu près sûr qu'il faut un domaine windows et donc Active Directory.
La seule chose que tu peux faire, c'est d'utiliser l'utilitaire fourni avec la version Windows de MIT Kerberos pour importer le ticket, et l'utiliser avec des clients supportant explicitement MIT Kerberos (eudora, certaines versions de putty).
> Par ailleurs, je me demandais bien ce que ça pourrais donner: pGina+Cygnus(avec Kerberos) et KDC Linux?
Cygwin +MIT kerberos. Hmm ça c'est peut-être amélioré, mais il y a encore deux ans c'était vraiment pas terrible. Prépare-toi à patcher le code ...
Alors pour Windows XP pro, je ne sais pas mais pour windows 2000, il existait un programme que tu pouvais télécharger dans le "kit administrateur" et qui permettait à une station Windows de s'authentifier auprès d'un KDC non Active Directory. Mais je pense que c'est très limité : je ne pense pas que tu puisses utiliser le ticket obtenu sous l'explorateur Windows pour accéder à un serveur CIFS, ni sous IE, ...
Si tu veux vraiment utiliser un KDC Linux, une solution viable est d'utiliser un serveur Active Directory, et de déclarer une relation de confiance (trust) entre le realm KDC et le realm AD.
Tout ceci est décrit dans le bouquin d'O'Reilly sur Kerberos que je te conseille vivement. Sinon, il faut attendre Samba 4.
Entre parenthèse je trouve que sur cette affaire d'Active Directory, Microsoft exégère vraiment. Ils prétendent utiliser des protocoles standards (Kerberos, LDAP) et en fait dans le détail, si tu veux vraiment une interopérabilité Windows/Unix avec un vrai single-sign on, et bas tu es quasiment obligé de t'installer un Windows Server. Ca me semble un cas caractérisé de position dominante où ils utilisent leur monopole sur les OS de bureau pour conquérir un marché sur le serveur.
Il y a très longtemps que je n'ai pas fait de C, mais ça doit être quelque chose comme çà:
mystruct m;
mystruct m_ptr = &m;
send(fd, (void *)m_ptr, sizeof(m), 0);
Mais attention. Si ton client et ton serveur doivent fonctionner sur la même plateforme (même compilateurs, mêmes OS, mêmes architectures), ça doit passer (encore que ...). Sinon, tu peux avoir les problèmes suivants :
1° octets de bourrage dans la structure. Les compilateurs peuvent placer des octets supplémentaires dans la structure, de manière non normalisée.
Par exemple sur beaucoup d'architectures, les champs sont alignés au mot, donc si tu as un char et un long int comme champs, ta structure fera 8 octets :
* le char
* trois octets de remplissage
* les quatre octets du long.
Il y a des directives de preprocessing pour régler ce comportement.
2° attention aux représentations des int. Selon les architectures, l'octet de poids fort et codé au début ou à la fin. Par exemple c'est différent sur Intel et sur PowerPC.
Pour un comportement "propre", il faut avoir recours à des techniques un peu plus sophistiquées comme XDR ou beaucoup plus sophistiquées comme ASN.1.
Alors je ne sais pas répondre directement à ta question. Cependant tu peux trouver beaucoup de livres scientifiques/techniques à la Bibliothèque Publique d'Information à Beaubourg (Centre Pompidou). Par contre, il faut le lire sur place.
Alors le "." désigne le répertoire courant, de même que ".." désigne le répertoire parent. Quant au "/", il désigne le séparateur entre le répertoire.
Donc "./programme" désigne le fichier programme qui se trouve dans le répertoire courant, de même que "../programme" désigne le fichier programme qui se trouve dans le répertoire parent.
Alors au sujet de savoir pourquoi on ne peut pas faire simplement "programme", il faut savoir que quant tu fais quelque chose comme "ls" depuis le shell, celui-ci va chercher à exécuter ls en utilisant le contenu de la variable d'environnement PATH (pour connaître ton PATH, il faut faire echo $PATH sous bash). Si ton PATH contient, "/bin:/usr/bin" et que tu fais ls, le shell va chercher d'abord à exécuter /bin/ls. S'il n'avait pas trouvé /bin/ls il aurait tenter d'exécuter /usr/bin/ls puis /usr/bin/ls, etc. Incidemment si tu ouvres une fenêtre de console, et que tu tentes de faire unset PATH, puis ls tu vas obtenir une erreur.
Il est possible de mettre le répertoire "." dans son PATH, (dans ce cas, la commande programme marche s'il y a bien un fichier exécutable programme) mais ça peut poser un problème de sécurité. Imagine que dans le répertoire /tmp un petit malin crée un script sl qui efface tout le disque (rm -rf /) et que root arrive dans le répertoire /tmp, qu'il tape sl au lieu de ls (ça m'arrive régulièrement). Je te laisse imaginer ce qui se passe.
Q1: Je ne peux pas répondre n'étant pas un utilisateur d'EVMS. Je pense que LVM est un peu plus répandu.
Pour la mise en oeuvre, on ne sait pas quelle distribution tu utilises.
Sous Debian, il n'y a pas grand chose à faire de plus que aptitude install lvm2 pour utiliser LVM. Pour EVMS, il semble qu'il faille installer un patch du noyau.
Sur la stabilité, LVM a été écrit par Sistina qui ne sont pas des rigolos et EVMS par IBM, je crois et ce ne sont pas exactement des rigolos non plus. Je pense qu'EVMS a plus de fonctionnalités que LVM (voir Q4).
Q3: Alors c'est possible. Mais selon les distributions, il faut bidouiller à l'installation. En outre si jamais ton LVM est en carafe, si / est sur LVM tu devras utiliser un live cd pour utiliser les utilitaires LVM (vgchange, vgscan, ...). Par contre il faut au minimum une partition /boot hors du LVM. Je pense qu'elle peut être aussi petite que 10 Mo. En ce qui me concerne, je garde toujours ma partition / hors LVM, je pense que ça évite quand même pas mal d'ennuis. Elle fait de l'ordre de 50 Mo.
Pour le swap, il n'y à mon avis aucun problème à ce qu'il soit sur LVM.
Q4: Alors sous LVM, je ne pense pas que tu pourras l'ajouter au raid software directement. Théoriquement, tu dois pouvoir l'ajouter sous forme d'un nouveau physical volume (PV) puis ajouter celui-ci à ton volume group (VG), mais tu n'auras pas envie de faire ça, parce que tout ton volume group va devenir dépendant de ton nouveau disque dur, ce qui fait que si celui crash, tu perds tout ton VG, ce qui équivaut à dire que ton raid devient à peu près inutile.
Tu devrais creuser la doc d'EVMS parce que je me demande justement si ce n'est pas sur ce point qu'il est supérieur à LVM.
Si tu veux tester des trucs sur raid, LVM et EVMS sur un PC lambda, tu peux utiliser des partitions loopbacks comme volume physique.
Si c'était Microsoft ou la plupart des autres vendeurs de logiciels propriétaires, on aurait dans la description du projet un simple message marketing du genre "la solution ultime pour sécuriser votre réseau d'entreprises", avec aucune discussion sur les limites, ni aucune description des mécanismes utilisés.
"Dormez, braves administrateurs, nous nous occupons de votre sécurité". Moi je trouve qu'un grand avantage du logiciel libre, c'est une certaine transparence. Rien qu'en regardant la page web du projet tu te fais une idée de ce qui marche, de ce qui ne marche pas (ou pas encore).
En plus maintenant, les vendeurs de logiciels propriétaires ne vendent même plus de softs, ils vendent des "solutions"... On ne comprend même plus ce que font les produits qu'ils vendent. Un exemple parmi d'autres : http://www.macrovision.com/.maximize the value of your content and software wouah ! TIens c'est nos amis justement :ils sont spécialisés dans le DRM. Ils affirment pouvoir sécuriser les DVD même vis-à-vis de deCSS, tout en continuant à fonctionner sur la majorité des lecteurs autorisés existants. Comment ? Mystère ?
> L'approche "forcer l'authentification de chaque utilisateur" est plus
> sécurisante à mon sens. C'est bien sûr discutable :)
Bien sûr. Moi, je parlais juste de la phase ultérieure où sur une machine multi-postes - donc avec plusieurs utilisateurs authentifiés sur Nuauth - il s'agit de repérer à quel utilisateur associer la nouvelle connexion.
> Idée séduisante sur le papier, mais qui demande une [trop?] grande
> confiance au poste client.
Et justement, c'est le client qui disait : c'est moi qui ai ouvert cette connexion. Donc, je trouvais que c'était un point faible mais Victor a levé une partie de mes doutes.
> De plus, ceci
> suppose que le pirate soit authentifié auprès de nuauth ... donc qu'il
> ait un compte ou volé un compte
Oui je suppose que le "pirate" est un utilisateur légitime de nufw qui veut voler la connexion d'un autre utilisateur sur la même machine.
> Hum ... tu veux dire que le client pirate répond "c'est moi qui ait
> ouvert la connexion" puis arrive à récupérer les paramètres de la
> socket (IP + TCP/UDP) ? Sous Linux, je vois mal comment récupérer
> les paramètres d'une socket TCP/IP, et donc la voler.
C'est ça un "yes-client" en quel que sorte. Tu as raison, les paramètre de la socket vont rester attachés à l'utilisateur, donc
tout ce que va avoir gagné notre pirate, c'est que la connexion ouverte par l'utilisateur va récupérer les credentials du pirate, et je doute que ça lui soit très utile.
Honnêtement, c'est vraiment bien pensé ce truc ...
Moi aussi j'étais un peu gêné par cette limitation.
Finalement le problème c'est que sur une machine multi-utilisateurs, tu peux faire tourner un client pirate pour voler les connexions de tes petits camarades (seulement ceux qui sont actuellement connectés sur la même machine, ce qui n'est pas mal).
Je pense que pour éviter que sur une même machine des utilisateurs d'une application de single sign on ne se volent les sessions les uns les autres, il faut d'une certaine manière faire confiance aux clients. Regarde Kerberos par exemple, tu pourrais imaginer que le programme d'acquisition des tickets (kinit) es mal foutu, et qu'il va stocker tous les tickets dans /tmp avec les droits 777 . Dans ce cas les utilisateur peuvent se piquer leurs sessions les uns aux autres. Donc, quelque part le problème pour éviter le vol de sessions entre les utilisateurs d'une même machine cliente est le problème de l'administrateur de la machine cliente. Naturellement root peut voler tous les sessions de tout le monde avec su mais ça on ne peut pas y faire grand chose.
Alors voilà ce que je me disais : au lieu d'avoir autant de clients que d'utilisateurs connectés, ne serait-il pas possible d'avoir un seul client sur la machine, tournant sous le compte root, qui se chargerait de faire le chef d'orchestre, et de certifier que la connexion ouverte sur TCP sur le port 15722 a bien été ouvert par l'utilisateur fblanche (par exemple) ? Je ne sais pas si c'est possible, et en outre j'ai l'impression que ce client ne serait pas portable sur tous les systèmes, mais bon voilà pour mes suggestions à 2 francs 50.
Et c'est même pire que ça. Les interpréteurs/compilateurs/machines virtuelles java, perl, python, ruby, c# (en tout cas mono, celui de Microsoft je ne sais pas), ocaml sont tous eux-mêmes en grande partie écrits en C/C++.
Je ne pense pas que ça soit ça. Ton fichier s'appelle probablement Configuration.java et ta classe Configuration. Ta classe, après d'éventuels import commence par :
> public class Configuration {
> (...)
> }
Ou alors elle s'appelle Configuration.java, et se trouve dans le fichier Configuration.java.java.
Normalement, si ton les fichier Configuration.java que XQuery.java code se trouvent dans le même répertoire java/jdk/bin, normalement, tu n'as pas besoin de directive import pour la classe Configuration (pour les autres non plus).
> cd java/jdk/bin
> javac XQuery.java
doit marcher. Si ça ne marche toujours pas, essaie :
> export CLASSPATH=$CLASSPATH:.
> cd java/jdk/bin
> javac XQuery.java
Le système de classes et de package java n'est pas très intuitif.
Je te conseille d'aller voir le document suivant.
# mod_perl non installé ?
Posté par tontonflingueur . En réponse au message Apache::ASP CPAN. Évalué à 2.
> LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so
(chemins à adapter, bien sûr) et peut-être aussi
> PerlModule Apache2
@+
[^] # Re: plusieurs possibilités...
Posté par tontonflingueur . En réponse au message Mplayer, XV et Root sont dans un bateau.. Évalué à 1.
[^] # Re: failsafe
Posté par tontonflingueur . En réponse au message Impossible de lancer X ou un terminal. Évalué à 3.
ou passer le paramètre init 3 au boot du kernel sous Grub. (Normalement Grub te permets de le faire en appuyant sur e au boot). Chez moi la commande est:
tu la modifies pour rajouter init 3. Moi je ferais:
Soit effectivement tu bootes sur un LiveCD, tu montes ta partition root et tu édites le fichier /mnt/broken_system/etc/inittab
Tu repères la ligne où il y a
et tu la remplaces par
En ce qui me concerne, je passe toujours le niveau d'init par défaut à 3 avant toute manipulation de X pour éviter ce problème.
# Re: MANDRAKE 10.1
Posté par tontonflingueur . En réponse au message MANDRAKE 10.1. Évalué à 1.
[^] # Re: Nommage des applications
Posté par tontonflingueur . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
http://sam.zoy.org/libcaca/
Au début je me suis dit, dommage comme nom ça passe vraiment pas en français.
Mais en fait le développeur est un francophone qui assume complètement (voir le logo).
[^] # Re: Athentification Windows XP PRO et KDC Linux
Posté par tontonflingueur . En réponse au message Athentification Windows XP PRO et KDC Linux. Évalué à 1.
Quels résultats attends-tu ? Est-ce que ton utilisateur arrive à se loguer ? AMHA par la suite, il n'y a aucune chance qu'un client Microsoft quelconque (Outlook, IE, l'explorateur de fichiers, client SQL Server, ...) puisse utiliser le ticket obtenu pour faire quoi que ce soit. Pour cela, je suis à peu près sûr qu'il faut un domaine windows et donc Active Directory.
La seule chose que tu peux faire, c'est d'utiliser l'utilitaire fourni avec la version Windows de MIT Kerberos pour importer le ticket, et l'utiliser avec des clients supportant explicitement MIT Kerberos (eudora, certaines versions de putty).
> Par ailleurs, je me demandais bien ce que ça pourrais donner: pGina+Cygnus(avec Kerberos) et KDC Linux?
Cygwin +MIT kerberos. Hmm ça c'est peut-être amélioré, mais il y a encore deux ans c'était vraiment pas terrible. Prépare-toi à patcher le code ...
# Et si tu essaies avec smbclient ?
Posté par tontonflingueur . En réponse au message Samba membre d'un domaine NT. Évalué à 2.
smbclient -U <user nt> -W <domaine nt> \\\\<serveur linux>\\<partage linux>
Et rentre ton mot de passe NT. Qu'est-ce que ça dit ?
# Re: Athentification Windows XP PRO et KDC Linux
Posté par tontonflingueur . En réponse au message Athentification Windows XP PRO et KDC Linux. Évalué à 1.
Si tu veux vraiment utiliser un KDC Linux, une solution viable est d'utiliser un serveur Active Directory, et de déclarer une relation de confiance (trust) entre le realm KDC et le realm AD.
Tout ceci est décrit dans le bouquin d'O'Reilly sur Kerberos que je te conseille vivement. Sinon, il faut attendre Samba 4.
Entre parenthèse je trouve que sur cette affaire d'Active Directory, Microsoft exégère vraiment. Ils prétendent utiliser des protocoles standards (Kerberos, LDAP) et en fait dans le détail, si tu veux vraiment une interopérabilité Windows/Unix avec un vrai single-sign on, et bas tu es quasiment obligé de t'installer un Windows Server. Ca me semble un cas caractérisé de position dominante où ils utilisent leur monopole sur les OS de bureau pour conquérir un marché sur le serveur.
[^] # Re: Il faut caster le pointeur sur la structure, mais attention ...
Posté par tontonflingueur . En réponse au message caster en une structure. Évalué à 1.
# Il faut caster le pointeur sur la structure, mais attention ...
Posté par tontonflingueur . En réponse au message caster en une structure. Évalué à 5.
Mais attention. Si ton client et ton serveur doivent fonctionner sur la même plateforme (même compilateurs, mêmes OS, mêmes architectures), ça doit passer (encore que ...). Sinon, tu peux avoir les problèmes suivants :
1° octets de bourrage dans la structure. Les compilateurs peuvent placer des octets supplémentaires dans la structure, de manière non normalisée.
Par exemple sur beaucoup d'architectures, les champs sont alignés au mot, donc si tu as un char et un long int comme champs, ta structure fera 8 octets :
* le char
* trois octets de remplissage
* les quatre octets du long.
Il y a des directives de preprocessing pour régler ce comportement.
2° attention aux représentations des int. Selon les architectures, l'octet de poids fort et codé au début ou à la fin. Par exemple c'est différent sur Intel et sur PowerPC.
Pour un comportement "propre", il faut avoir recours à des techniques un peu plus sophistiquées comme XDR ou beaucoup plus sophistiquées comme ASN.1.
[^] # Re: le P2P c'est quoi?
Posté par tontonflingueur . En réponse à la dépêche Le conseil constitutionnel aggrave encore DADVSI. Évalué à 5.
Tout à fait, et je voudrais ajouter qu'il y a même une RFC à ce sujet.
http://www.faqs.org/rfcs/rfc2549.html
# Re: emprunt de livre technique ou recherche livre d'occaz
Posté par tontonflingueur . En réponse au message emprunt de livre technique ou recherche livre d'occaz. Évalué à 2.
@+
# Signification de "./"
Posté par tontonflingueur . En réponse au message Signification de "./". Évalué à 4.
Donc "./programme" désigne le fichier programme qui se trouve dans le répertoire courant, de même que "../programme" désigne le fichier programme qui se trouve dans le répertoire parent.
Alors au sujet de savoir pourquoi on ne peut pas faire simplement "programme", il faut savoir que quant tu fais quelque chose comme "ls" depuis le shell, celui-ci va chercher à exécuter ls en utilisant le contenu de la variable d'environnement PATH (pour connaître ton PATH, il faut faire echo $PATH sous bash). Si ton PATH contient, "/bin:/usr/bin" et que tu fais ls, le shell va chercher d'abord à exécuter /bin/ls. S'il n'avait pas trouvé /bin/ls il aurait tenter d'exécuter /usr/bin/ls puis /usr/bin/ls, etc. Incidemment si tu ouvres une fenêtre de console, et que tu tentes de faire unset PATH, puis ls tu vas obtenir une erreur.
Il est possible de mettre le répertoire "." dans son PATH, (dans ce cas, la commande programme marche s'il y a bien un fichier exécutable programme) mais ça peut poser un problème de sécurité. Imagine que dans le répertoire /tmp un petit malin crée un script sl qui efface tout le disque (rm -rf /) et que root arrive dans le répertoire /tmp, qu'il tape sl au lieu de ls (ça m'arrive régulièrement). Je te laisse imaginer ce qui se passe.
Voilà
# Re: Partitionnement, RAID Soft & LVM2 vs EVMS
Posté par tontonflingueur . En réponse au message Partitionnement, RAID Soft & LVM2 vs EVMS. Évalué à 4.
Pour la mise en oeuvre, on ne sait pas quelle distribution tu utilises.
Sous Debian, il n'y a pas grand chose à faire de plus que aptitude install lvm2 pour utiliser LVM. Pour EVMS, il semble qu'il faille installer un patch du noyau.
Sur la stabilité, LVM a été écrit par Sistina qui ne sont pas des rigolos et EVMS par IBM, je crois et ce ne sont pas exactement des rigolos non plus. Je pense qu'EVMS a plus de fonctionnalités que LVM (voir Q4).
Q2: Non. http://oss.sgi.com/projects/xfs/faq.html#resize
Q3: Alors c'est possible. Mais selon les distributions, il faut bidouiller à l'installation. En outre si jamais ton LVM est en carafe, si / est sur LVM tu devras utiliser un live cd pour utiliser les utilitaires LVM (vgchange, vgscan, ...). Par contre il faut au minimum une partition /boot hors du LVM. Je pense qu'elle peut être aussi petite que 10 Mo. En ce qui me concerne, je garde toujours ma partition / hors LVM, je pense que ça évite quand même pas mal d'ennuis. Elle fait de l'ordre de 50 Mo.
Pour le swap, il n'y à mon avis aucun problème à ce qu'il soit sur LVM.
Q4: Alors sous LVM, je ne pense pas que tu pourras l'ajouter au raid software directement. Théoriquement, tu dois pouvoir l'ajouter sous forme d'un nouveau physical volume (PV) puis ajouter celui-ci à ton volume group (VG), mais tu n'auras pas envie de faire ça, parce que tout ton volume group va devenir dépendant de ton nouveau disque dur, ce qui fait que si celui crash, tu perds tout ton VG, ce qui équivaut à dire que ton raid devient à peu près inutile.
Tu devrais creuser la doc d'EVMS parce que je me demande justement si ce n'est pas sur ce point qu'il est supérieur à LVM.
Si tu veux tester des trucs sur raid, LVM et EVMS sur un PC lambda, tu peux utiliser des partitions loopbacks comme volume physique.
Voilà
[^] # Re: Je me réponds à moi même
Posté par tontonflingueur . En réponse au message Compilation de Qt. Évalué à 1.
http://www.linuxfromscratch.org/blfs/view/svn/x/lib.html#qt
# RE: Must have: Les liens que l'on doit obligatoirement connaître
Posté par tontonflingueur . En réponse au message Must have: Les liens que l'on doit obligatoirement connaître. Évalué à 2.
http://www.tldp.org
Il y a un petit drapeau français en haut à droite, mais évidemment les traductions françaises ne sont pas toujours les plus à jour.
[^] # Re: xvjf !
Posté par tontonflingueur . En réponse au message probléme commande tar. Évalué à 2.
Fait un petit coup de ls -l sur ton fichier. Ca serait pas un lien symbolique vers un fichier dont la cible n'existe pas, des fois ?
# perl & php
Posté par tontonflingueur . En réponse au message perl & php. Évalué à 2.
http://search.cpan.org/~miyagawa/PHP-Session-0.26/
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . En réponse à la dépêche NuFW 2.0, nouvelle version majeure du pare-feu authentifiant. Évalué à 7.
"Dormez, braves administrateurs, nous nous occupons de votre sécurité". Moi je trouve qu'un grand avantage du logiciel libre, c'est une certaine transparence. Rien qu'en regardant la page web du projet tu te fais une idée de ce qui marche, de ce qui ne marche pas (ou pas encore).
En plus maintenant, les vendeurs de logiciels propriétaires ne vendent même plus de softs, ils vendent des "solutions"... On ne comprend même plus ce que font les produits qu'ils vendent. Un exemple parmi d'autres : http://www.macrovision.com/. maximize the value of your content and software wouah ! TIens c'est nos amis justement :ils sont spécialisés dans le DRM. Ils affirment pouvoir sécuriser les DVD même vis-à-vis de deCSS, tout en continuant à fonctionner sur la majorité des lecteurs autorisés existants. Comment ? Mystère ?
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . En réponse à la dépêche NuFW 2.0, nouvelle version majeure du pare-feu authentifiant. Évalué à 2.
> sécurisante à mon sens. C'est bien sûr discutable :)
Bien sûr. Moi, je parlais juste de la phase ultérieure où sur une machine multi-postes - donc avec plusieurs utilisateurs authentifiés sur Nuauth - il s'agit de repérer à quel utilisateur associer la nouvelle connexion.
> Idée séduisante sur le papier, mais qui demande une [trop?] grande
> confiance au poste client.
Et justement, c'est le client qui disait : c'est moi qui ai ouvert cette connexion. Donc, je trouvais que c'était un point faible mais Victor a levé une partie de mes doutes.
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . En réponse à la dépêche NuFW 2.0, nouvelle version majeure du pare-feu authentifiant. Évalué à 4.
> suppose que le pirate soit authentifié auprès de nuauth ... donc qu'il
> ait un compte ou volé un compte
Oui je suppose que le "pirate" est un utilisateur légitime de nufw qui veut voler la connexion d'un autre utilisateur sur la même machine.
> Hum ... tu veux dire que le client pirate répond "c'est moi qui ait
> ouvert la connexion" puis arrive à récupérer les paramètres de la
> socket (IP + TCP/UDP) ? Sous Linux, je vois mal comment récupérer
> les paramètres d'une socket TCP/IP, et donc la voler.
C'est ça un "yes-client" en quel que sorte. Tu as raison, les paramètre de la socket vont rester attachés à l'utilisateur, donc
tout ce que va avoir gagné notre pirate, c'est que la connexion ouverte par l'utilisateur va récupérer les credentials du pirate, et je doute que ça lui soit très utile.
Honnêtement, c'est vraiment bien pensé ce truc ...
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . En réponse à la dépêche NuFW 2.0, nouvelle version majeure du pare-feu authentifiant. Évalué à 2.
Finalement le problème c'est que sur une machine multi-utilisateurs, tu peux faire tourner un client pirate pour voler les connexions de tes petits camarades (seulement ceux qui sont actuellement connectés sur la même machine, ce qui n'est pas mal).
Je pense que pour éviter que sur une même machine des utilisateurs d'une application de single sign on ne se volent les sessions les uns les autres, il faut d'une certaine manière faire confiance aux clients. Regarde Kerberos par exemple, tu pourrais imaginer que le programme d'acquisition des tickets (kinit) es mal foutu, et qu'il va stocker tous les tickets dans /tmp avec les droits 777 . Dans ce cas les utilisateur peuvent se piquer leurs sessions les uns aux autres. Donc, quelque part le problème pour éviter le vol de sessions entre les utilisateurs d'une même machine cliente est le problème de l'administrateur de la machine cliente. Naturellement root peut voler tous les sessions de tout le monde avec su mais ça on ne peut pas y faire grand chose.
Alors voilà ce que je me disais : au lieu d'avoir autant de clients que d'utilisateurs connectés, ne serait-il pas possible d'avoir un seul client sur la machine, tournant sous le compte root, qui se chargerait de faire le chef d'orchestre, et de certifier que la connexion ouverte sur TCP sur le port 15722 a bien été ouvert par l'utilisateur fblanche (par exemple) ? Je ne sais pas si c'est possible, et en outre j'ai l'impression que ce client ne serait pas portable sur tous les systèmes, mais bon voilà pour mes suggestions à 2 francs 50.
@+
[^] # rdiff-backup
Posté par tontonflingueur . En réponse au message Solution de sauvegarde. Évalué à 2.
[^] # Re: Eheh
Posté par tontonflingueur . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 1.
# Ah le système de classe java ...
Posté par tontonflingueur . En réponse au message Test de XQuery - Problème de Compilation. Évalué à 1.
> import Configuration.java;
Je ne pense pas que ça soit ça. Ton fichier s'appelle probablement Configuration.java et ta classe Configuration. Ta classe, après d'éventuels import commence par :
> public class Configuration {
> (...)
> }
Ou alors elle s'appelle Configuration.java, et se trouve dans le fichier Configuration.java.java.
Normalement, si ton les fichier Configuration.java que XQuery.java code se trouvent dans le même répertoire java/jdk/bin, normalement, tu n'as pas besoin de directive import pour la classe Configuration (pour les autres non plus).
> cd java/jdk/bin
> javac XQuery.java
doit marcher. Si ça ne marche toujours pas, essaie :
> export CLASSPATH=$CLASSPATH:.
> cd java/jdk/bin
> javac XQuery.java
Le système de classes et de package java n'est pas très intuitif.
Je te conseille d'aller voir le document suivant.
http://www.commentcamarche.net/java/javapack.php3
@+