CoinKoin a écrit 698 commentaires

Au lieu de Minidoux, je suggère "petitmou" :-) .

>cat commentaire_suivant
Ah ! je comprends maintenant. Merci de l'explication :)

Donc si j'ai bien compris, comme j'utilise un environnement de bureau appelé Gnome, au dessus des outils GNU, je dois appellé mon système Gnome/GNU/Linux. De plus, la maintenance de mon système est gérée par les outils Gentoo, ce qui donne Gnome/Gentoo/Gnu/Linux. Par contre, lorsque que j'utilise le gestionnaire de fichier Rox, est-ce-que je dois dire Rox/Gnome/Gentoo/GNU/Linux ?

warning : truc poilu en vue.

kernel panic : attempt to troll about OS name!

Ah, un détail, quand même : plutôt que le sticky bit, qui peut être supprimé par le propriétaire du répertoire, fais plutôt un "chown root:root ." .Comme ça, pas de mauvaises blagues possibles.

Et puis, pour faire encore plus propre, tu peux carément te créer un utilisateur dédié aux .jsp, nommé par exemple jspuser, et faire un "chown jspuser:jspuser ." et "chown jspuser:jspuser -R *" .

Comme ça, tu n'auras pas à te loguer en root où à faire su root pour mettre à jour tes images, ce qui est préférable. Le login en root doit vraiment être réduit au strict minimum.

Ah, pardon, Cho7, je n'avais pas vu que tu étais auteur de la demande d'éclaircissements ainsi que de la réponse. Eh bien oui, c'est comme cela qu'il faut procéder.

L'explication de cho7 est la bonne.

Attention quand même, avec l'option -R, chown va se comporter de façon récursive, et donc changer aussi le propriétaire des fichiers des sous-répertoires de celui-ci. Si ce n'est pas souhaitable, enlève l'option -R.

>"D'autre part seuls les contrats rédigés en langue française sont valides en droit français. "

Ce n'est pas si clair, parce que le droit européen en juge différemment. Or le droit européen aussi est applicable en France.

>Pas très clair ton truc... On parle des droits des auteurs d'un programme et en te lisant je comprends: tu es l'auteur d'un programme en GPL et des mecs font des modifs, tu n'aurais pas le droit de demander le source des modifs ?

Exactement. La GPL impose de distribuer le source avec le code compilé du programme, mais ne précise pas que, lorsqu'on modifie un programme, on doive le distribuer.

Simplement, quand un programme est distribué sous GPL, il est rare qu'on ne parvienne pas à se le procurer légalement, et donc, on est autorisé à demander le source.

>"ça fait des années que j'ai pas connu un plantage sous Windows"

Et alors? Moi aussi, ça fait des années que je n'ai pas utilisé de Windows... ;-)

========>[]

Et si tu créais dans /tmp/<nom_fichier_enemy_territory> un lien symbolique vers ~/tmp/<nom_fichier_enemy_territory> ? Bon je pense que ça ne peut marcher que si tu parviens à bloquer le programme alors qu'il a créé ce fichier et qu'il l'a refermé, pour le rouvrir plus tard, en faisant entre-temps un mv et en créant le lien.

Sinon, il y a des astuces de retaillage de partitions qui trainent sur linuxfr, mais je ne les connais pas bien.

Bonne chance!

Hé mais dis-donc, toi, à propos de licences libres...
Est-ce que tu as vu les derniers commentaires de ton journal "le droit d'écrire" ? Parce que nous sommes plusieurs à attendre une réponse...

http://linuxfr.org/~khane/14833.html(...)

>Qu'on se le dise 52 licences c'est très peu vu l'ensemble des produits qu'elles recouvrent.

Oui, d'accord, mais, dans le libre, cela pose un autre problème. Les licenses libres sont justement conçues pour permettre l'échange de code entre divers projets, pour ne pas avoir à réinventer la roue à chaque fois.

Le problème, c'est qu'avec 52 licenses, on n'est plus obligé de passer 3 heures à réinventer la roue, mais on passe 3 heures à vérifier sa compatibilité juridique avec l'essieu. Bon, évidemment, je caricature, mais c'est bien là que se situe le noeud du problème.

Sans compter que certaines licenses libres sont incompatibles avec d'autres, ce qui faut qu'au bout de 3 heures, le programmeur se rend compte qu'il va quand-même devoir réinventer l'essieu...

>J'ai utilisé un malloc pour allouer de la mémoire au struct, mais y'a pleins d'erreurs. j'essaye encore.

Pas besoin de malloc! A mon avis, le code que je t'ai donné est "sale", c'est-à-dire qu'il n'est pas codé proprement (par exemple, le chemin "/proc" ne devrait pas s'y trouver en dur, mais faire l'objet d'un #define, lui aussi), mais il est parfaitement fonctionnel.

En revanche, il faut que tu effectues les #include nécessaires, et je pense que c'est ça que tu as oublié. Ces #include sont décrits en détail en haut des pages de "man" correspondant aux appels système employés, ici stat() (et sprintf(), même si ce n'est pas un vrai appel-système).

"man 2 stat" donne :

 #include <sys/types.h>

#include <sys/stat.h>

#include <unistd.h>

("man 2 stat", parce que man stat, c'est juste pour la commande shell "stat").

Pour sprintf, il faut sans doute ajouter #include <stdio.h> , et peut-être #include <string.h> (je n'ai pas de man 3 installé, actuellement, or sprintf est décrite dans une page de la section 3 du man, donc je ne suis pas sûr).

Sache aussi que ces #include doivent être placés au tout début de ton fichier.

En conclusion, si tu es débutant en C, sache que les pages de man, man 2 et man 3 surtout, sont particulièrement utiles à la programmation dans ce langage. Même si leur lecture, au début, est fastidieuse...

Peut-être qu'il voulait limiter le risque de bourrage de /tmp par un utilisateur mal intentionné...
"cat /dev/zero | tr -c a z >/tmp/bourretmp" ;-)

>Y'a aussi WindowMaker comme gestionnaire assez léger (que j'utilise moi même). A essayer.

Effectivement. Il y a aussi IceWm, fvwm2 ou encore fvwm95. Euh, personnellement, je ne recommande pas trop ces deux derniers. J'ai aussi entendu parler de owm, mais je ne l'ai jamais essayé.

Crée-toi deux utilisateurs distincts, l'un utilisera KDE comme gestionnaire de fenêtres, l'autre Xfce. Bien sûr, le deuxième aura accès aux programmes de KDE, mais il lui suffira de ne pas les lancer.

Sinon, si tu veux vraiment jouer avec grub, sache qu'effectivement, la solution (préconisée plus haut) du jeu avec les niveaux d'init est à peu près la seule valable, mais que, à moins de placer KDE sur une partition non montée dans le cas du boot pour utilisateur "pressé", cela ne changera rien par rapport au jeu sur deux utilisateurs...

Mais chez moi, c'était avec une Mandrake 9.2.1 . Cela dit, comme je soupçonne les pilotes de périphériques, il est possible que la même chose t'arrive...

Moi, mon problème était plutôt au niveau de la gestion des haut-parleurs ("oubli" de celui de droite). Je suis parvenu à le rétablir par la manoeuvre suivante :
Lancement de mon Mplayer favori, puis login en root, et mise en veille forcée de l'ordi (par apm -S ou apm -s, je ne sais plus, essaie les deux).

Je ne sais pas si cela marchera chez toi, mais qui ne tente rien n'a rien...

P.S. : apm ou apmd? Je ne sais plus non plus. RTFM...

>Fais alors en sorte que le fichiers JSP t'appartiennent et que l'utilisateur Tomcat ait seulement les droits en lecture dessus.


Désolé, mais ce point-là ne sert à rien... En fait, s'il n'a plus le droit d'écriture sur le fichier, cela signifie qu'il n'a plus le droit de le modifier. Il conserve le droit de changer ses droits (héhéhé... adieu la protection), et même de le supprimer, car le droit de suppression d'un fichier dépend du répertoire dans lequel celui-ci se trouve, et non des droits du fichier lui-même. En d'autres termes, si le répertoire à les droits 755 (drwxr-xr-x), alors, comme le droit d'écriture, dans un répertoire, correspond au droit de création et de suppression de fichiers, ton utilisateur tomcat aura toujours le droit de supprimer tous les fichiers du répertoire.

Tu peux d'ailleurs faire l'expérience : crée un fichier, mets-le en mode 000 (---------), puis essaye de le supprimer... Pas de problème!

Il existe tout de même une solution, particulièrement tordue, pour empêcher totalement un utilisateur non root de supprimer un fichier qui lui appartient. Il s'agit de créer, sur la même partition que les fichiers en question, un répertoire appartenant à un autre utilisateur, et de placer, dans ce répertoire, des liens matériels (et non symboliques) pointant les fichiers à protéger. Ensuite, il faut retirer tous les droits sur ce répertoire (et non son contenu) à l'utilisateur visé (ici, tomcat) : n'ayant plus d'accès à ces fichiers, il ne peut les supprimer, même s'ils lui appartiennent! Et si un pirate prend le contrôle de tomcat et lui fait effacer ses fichiers, tu n'auras plus qu'à les récupérer dans ce répertoire.

Bon, cela dit, cela n'empêche malheureusement pas le pirate de modifier les données de ces fichiers, et en particulier, il peut les tronquer à une taille nulle, ce qui revient (presque) à une suppression. Pour cela, deux parades :
-Soit tu retires les droits d'écriture à Tomcat sur ces fichiers, en sachant que cela est contournable par un bon pirate (il suffit de rétablir les droits),
-Soit tu emploies une solution bien plus simple, et qui t'évite aussi d'avoir à créer le répertoire de liens matériels : tu attribues les images de tomcat, en mode r--r--r--, à un utilisateur autre que celui qui lance le processus tomcat! Et le tour est joué.

CoinKoin

Ah, d'accord, je n'avais pas compris que ce message d'erreur était obtenu en cas de suppression depuis le poste client... Bon, à mon avis, cela doit être la traduction, par samba, de l'impossibilité, sous UNIX/Linux, de supprimer un répertoire non vide (sauf par unlink, par le root, et encore, c'est fortement déconseillé).
Manifestement, samba traduit (en gros) un ordre de suppression par "rm", et non "rm -rf", ce qui est plutôt logique (pour éviter la suppression accidentelle de fichiers).

Bon, si tu veux y remédier, je pense que ta seule solution (à moins que Samba soit reconfigurable sur ce point?), c'est d'imposer à tes utilisateurs de ne jamais supprimer de répertoire non vide. Cela dit, je n'ai jamais installé de Samba....

>1/ Je crée un dossier dans lequel je crée un autre dossier et j'essaye de supprimer le dossier parent : "device or resource busy". Même après un redémarrage, histoire d'éviter les verrous. Avec les fichiers, il n'y a pas ce problème.

Je te suggère d'arrêter le service samba avant d'essayer la suppression. Bon, ça, c'est juste si tu veux une solution tout de suite, immédiatement utilisable, ce n'est pas jouable à long terme.

Ca c'est marrant, le CoinKoin a oublié la balise fermante < / p r e >. On le condamne à aller au Coin?

J'ai déjà fait une fois un code de ce genre-là, malheureusement je ne l'ai pas sous la main. La solution que j'avais employé, et qui était très efficace, était de parcourir bêtement /proc. Dans ton cas, tu n'auras qu'à faire :

int i;

struct stat buffer;

#define MAX_PID 32768

#define UID_UTILISATEUR /* ha ben je ne sais pas, moi! tape "id" dans un shell */

for(i=&;i<MAX_PID;i++){

   sprintf(chemin,"/proc/%d",i);

   if((stat(chemin,&buffer)!=-1) && (buffer.st_uid==UID_UTILISATEUR)){

      mettre_dans_fichier(i);

   }

}



Bon, c'est juste un code sale, pour te montrer comment ça marche, pour faire cela proprement, il faudrait par exemple récupérer MAX_PID au niveau des symboles exportés par le noyau (je crois qu'il se trouve là...).

Je crois que, comme l'existence de /tmp est un standard UNIX, beaucoup d'applis ont le chemin /tmp inscrit en dur dans leur code. Donc je crains que, pour bien des applis, cela ne marche pas...

Bon, voici quelques conseils pour avoir une configuration suffisament légère pour rester fluide :

Distrib : pas de préférence.

Gestionnaire de fenêtres : choisir quelque chose de léger. Le plus léger que je connaisse est twm, mais je précise qu'il a très peu de fonctionnalités. Il y a plus joli, comme par exemple fvwm, ou mieux encore fluxbox.

Pour OpenOffice : ah, ben, là, pas de choix, il n'y a pas d'alternative à OpenOffice.

Pour la navigation sur internet : le plus léger est sans conteste lynx (si l'on excepte le telnet en port 80 ;-) ), mais il est en mode texte. On peut aussi utiliser links dans une console texte, et activer les framebuffers pour avoir les images, mais ce n'est pas forcément simple. Toutefois, si tu n'as pas peur des problèmes d'affichage de ce logiciel (tu verras, sa présentation de certaines pages web est parfois... originale), je te conseille dillo, léger et exceptionnellement rapide.

Si, par contre, tu constates à l'expérience que ça ne te prend pas trop de ressources, tu peux employer mozilla firefox, comme beaucoup d'entre nous.

Pour ce qui est du traitement d'images, je n'y connais rien, donc je laisse d'autres participants à linuxfr répondre à cette question.

Essaie de lancer fvwm, fluxbox et gnome, et dis-nous ce qui marche...
Essaie aussi de créer un fichier .xinitrc contenant simplement la ligne "startkde", et de faire xinit -- :1 & dans une console texte.

>Tout le monde sait qu'un simple "while (1) fork() ;" peut mettre à genoux une becane.

Ha oui? Si tu as des quotas de processus par utilisateur, ce qui est courant, tu n'as qu'à te loguer au nom d'un autre utilisateur, de faire su, de récupérer les pids des processus qui forkent, de leur faire kill -STOP, puis kill -KILL, et enfin kill -CONT. J'avais même écrit un script qui faisait ça automatiquement, pour éviter le problème.

>Qu'un autre "dd if=/dev/zero of=/tmp/file" peut faire des ravages s'il n'y a pas de quota.


Ca non plus, ce n'est pas mortel. J'ai déjà eu à faire à ce genre de choses (ils sont marrants, ces étudiants!...), et j'ai rapidement repéré les processus en cause (ils ont des caractéristiques bizarres, avec un temps de calcul important et qui pourtant n'évolue plus, sauf quand on libère de la place, une taille en mémoire suspectement faible, et quelques autres détails...).
Il a alors suffi de les tuer pour retrouver une situation normale.


>Je suis sûr que ton swap et ta partition root ne sont pas cryptés et que beaucoup de machine que tu administres sont physiquement accessible par beaucoup de monde. Qu'il n'y a pas de mot de passe pour le BIOS/LILO/GRUB. Que par défaut ça boote sur le CD-ROM, que t'utilises le même mot de passe root pour toutes les bécanes, etc...

Je ne suis pas sûr que l'on parle de la même chose... On ne parle pas de PCs personnels, mais bien de machines de production, typiquement de serveurs universitaires. Dans l'école où je suis, aucun serveur n'est physiquement accessible par un non-administrateur, et je ne pense pas que les chargeurs de démarrage soient reconfigurables sans mot de passe.

Quant au cryptage de la partition swap et de la partition root, et à la possibilité de booter sur CD-ROM, ben, sans accès physique, je ne vois pas à quoi cela peut servir...