J'ai été faire un tour à Solutions Linux aujourd'hui. A l'entrée, Novell avait mis une quinzaine de PC sous SLED 10 en libre service sans réelle surveillance.
En ressortant, suis passé à la FNAC du CNIT. Il y avait 2 PC sous Vista verrouillés présentant l'écran fixe de login...
Journal De la confiance relative dans son produit
1
fév.
2007
# public
Posté par Gluck_ (site web personnel) . Évalué à 0.
Certes, tout est verrouillé à la Fnac. J'espère qu'ils feront de même avec leurs éventuelles stations sous linux. Si c'est pour se taper des sessions trafiquées par des petits cons en manque de sensation, ça perd de son intérêt.
[^] # Re: public
Posté par CrEv (site web personnel) . Évalué à 2.
Maintenant, ça devrait peut-être changer un peu avec vista, mais les mauvaises habitudes toussa...
[^] # Re: public
Posté par BAud (site web personnel) . Évalué à 4.
:(){ :|:&};: # et valider, a suffi à ne plus trop bien faire marcher ces SLED...
[^] # Re: public
Posté par andeus . Évalué à 8.
[^] # Re: public
Posté par B16F4RV4RD1N . Évalué à 7.
pourquoi les distributions modernes ne mettent pas automatiquement une protection contre cela ?
mêmes questions que celles ici d'ailleurs :
http://devloop.lyua.org/blog/index.php?2005/05/24/24-tux-tra(...)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: public
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: public
Posté par IsNotGood . Évalué à 10.
De toute manière, ça n'a pas de sens et ça a déjà été discuté des milliers de fois par les spécialistes sécurités Linux.
Si un programme fait le con et forcke dans tous les sens, l'admin doit alors le virer.
Si un utilisateur fait le con et lance des programmes à la con ou fait des scripts à la con alors l'admin doit lui foutre un coup de pied au cul ou utiliser ulimit.
Et si l'utilisateur est aussi admin ? Ben dans ce cas c'est ses oignons.
[^] # Re: public
Posté par IsNotGood . Évalué à 4.
Un truc genre anti-virus qui surveille ce que tu tapes ?
Beurk.
Si c'est "ma" distribution, je ne veux pas de ça.
Si c'est pour faire un PC public, on n'a pas besoin de ça. Regardes les cybers cafés sous Linux.
Puis une solution est ulimit.
Mais si c'est *ma* distribution je ne veux pas qu'elle m'envoie balader de façon "tyranique". Si je fais un truc qui surcharge mon PC c'est mes oignons car c'est mon PC, ma mémoire vive, etc...
Je n'ai pas envis que Linux se transforme en Windows avec des tonnes d'espion pour soit disant te proteger et qu'au final 99% des utilisateurs désactives.
[^] # Re: public
Posté par Joc M . Évalué à 7.
C'est pas par ce que JE sais conduire que je demande à ce qu'on enlève les parapets des ponts, pour moi et pour les autres !!! Sinon, on met qu'un compte admin en arguant que MOI je sais ce que je fais sur MA distrib.
Finalement, quand on parle de sécurité, de userfriendliness, d'idéologie, on en arrive toujours aux même conclusions :
Assister l'utilisateur ou l'admin en herbe est nécessaire mais les gurus n'en veulent pas. Donc... on en arrive à l'obligation de fournir des distribs grand publique et des distibs sur mesure.
En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse... et NON sous debian/slackware/gentoo...
PS : ne voyez pas dans ce commentaire une classification des distributions GNU/Linux, il ne s'agit que d'exemples qui ont pour but d'illustrer mes propos.
[^] # Re: public
Posté par IsNotGood . Évalué à -1.
Tu mélanges un peu tout.
> Sinon, on met qu'un compte admin en arguant que MOI je sais ce que je fais sur MA distrib.
Tu peux parfaitement toujours utiliser le compte root. Le fais-tu ?
J'espère que non. Et si tu n'utilises pas le compte root, c'est TA décision.
S'il y a une distribution qui m'interdit l'accès au compte root pour soit disant ma sécurité, alors je la fous aux orties.
> En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse...
NON et NON !
Pourquoi il y aurait des fork sauvages sur TA bécane ?
Car TU as downloadé des programmes à la con que TU exécutes intentionnellement dans TON environnement utilisateur. Si un utilisateur est con au point de downloader et tester tout et n'importe, on aura beau faire, ça sera toujours le bordel.
De même, j'espère que tu n'installes pas tous les noyaux que tu trouves sur le web.
TON environnement utilisateur autorise 8000 process, ça écroule (et non plante, car ça ne doit pas faire planter l'OS) TA bécane. Et lors ? Ne relances pas, TOI, le programme qui fait écrouler TA bécane. C'est si compliqué ?
Qu'un OS se protège des attaques extérieures, OK, mille fois OK.
Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK.
Qu'un OS protège de la bêtise d'un utilisateur, alors NON et mille fois NON.
D'ailleur j'aime bien faire des conneries de temps en temps avec ma bécane.
L'OS met à disposition des ressources à un utilisateur (cpu, mémoire, etc). L'objectif d'un OS, n'est pas empêcher l'utilisation de ces ressources. C'est justement le contraire. Si l'utilisateur veut, de son propre chef, lancer un programme qui fait 16 000 fork, c'est ses oignons. Si la bécane le supporte et que l'utilisateur est content, tant mieux. Si la bécane ne le supporte pas, ben l'utilisateur ne relance plus ce programme. Fin de l'histoire.
[^] # Re: public
Posté par Gilles G. . Évalué à 1.
Tu ne t'es jamais dit que tout le monde n'est pas informaticien???
Ben je te l'annonce alors:
Tout le monde n'est pas informaticien!
Si si, promis.
[^] # Re: public
Posté par IsNotGood . Évalué à 0.
Mon dieu. J'ai dit que l'utilisateur doit apprendre à ne pas lancer un programme s'il c'est apperçu que ce programme écroule sa bécane. En fait, il n'y a rien à apprendre, les gens font ça d'instinct.
Toi tu prends les utilisateurs pour des cons, très très cons.
Ce n'est pas mon cas.
Pour finir, je n'ai jamais dit que j'étais contre les interfaces graphiques simples ou des outils d'administration simples.
Donc je ne vois pas où tu veux en venir.
> Ben je te l'annonce alors:
> Tout le monde n'est pas informaticien!
Ben je te l'annonce alors:
Les non informaticiens ne sont pas des cons !
[^] # Re: public
Posté par CoinKoin . Évalué à 2.
Comment t'aperçois-tu que c'était lui qui a été attaqué? (Si tu es non-informaticien)
Et est-ce qu'il ne serait pas préférable de protéger les débutants contre ce genre d'attaques?
[^] # Re: public
Posté par IsNotGood . Évalué à 4.
Dans ce cas, c'est un programme qui fait serveur ou qui est accessible depuis l'extérieur (par exemple bittorrent). Le comportement du programme ne dépend pas que de l'utilisateur. Dans ce cas, le programme peut (et souvent le fait) de lui même faire les appels systèmes qui vont bien pour que l'OS lui fournisse que ce dont il a besoin et pas plus. On voit ça avec les serveurs qui sont lancé en root, puis utilise capability, puis passe sous un compte non privilégié. C'est le programme, qui connait ce dont il a besoin, qui le fait. Ce n'est pas un programme tière qui le fait soit disant pour le bien de l'utilisateur.
Notes bien, que tout ce qui précède, ne limite pas l'utilisateur !
De plus, j'ai dit : "Qu'un OS se protège des attaques extérieures, OK, mille fois OK". C'est aussi valable pour les programmes pour qu'il se protège, celà va de soit.
> Comment t'aperçois-tu que c'était lui qui a été attaqué? (Si tu es non-informaticien)
"lui" ? qui "lui" ?
Le programme que tu viens de downloader ?
Un programme de la distribution ?
Si le programme vient de la distribution, il y aura une mise à jour, etc...
Si c'est un programme que tu as downloadé d'une source qui n'est pas de confiance, ben t'as pris des risques et c'est à toi de te demmerder.
Exécutes cette commande : "rm -r -f /"
Tu l'as fait ?
Si tu l'as fait, ton programme pour veiller à ta sécurité a marché ?
Si tu ne l'as pas fait, alors pourquoi ?
> (Si tu es non-informaticien)
Je suis informaticien. Ben si j'ai un programme qui supprimer des fichiers dans mon dos, ... ben je ne suis pas au courant non plus (ou du moins bien trop tard). Ce qui est dissimulé est par définition dissimulé. Une attaque fork bomb ne vas pas dire : "coucou, je vais faire une attaque".
Suivons ta logique, on met un truc pour détecter les fork bombs. Mais l'utilisateur après avoir downloadé un programme qui fait des fork bomb, peut aussi downloadé un programme qui supprime des fichiers du disque dur. Mieux, au-lui de downloader les programmes, il peuvent d'exécuter dans le navigateur comme les ActiveX de MS (puisqu'on a des trucs qui contrôle tout, on ne va pas se priver).
On fait quoi ?
On suit ta logique et on ajoute un truc qui détecte les suppressions de fichier et qui 9/10 les détecte trop tard....
Pire, considérons que tous ces trucs de surveillance marchent (c'est une supposition). Ben il y aura plein de programmes à la con d'installés et de développés car les gens se disent qu'il y aura le contrôle "big brother" qui va ratrapper la situation.
Bref, c'est le modèle Windows/antivirus qui suxe grave. Pourtant les anti-virus sont tout plein de bonne intention, les efforts marketing pour nous le faire croire sont remarquables. Windows aussi est tout plein de bonnes intention et n'arrête pas de nous le répéter (comme ton truc de détection de "fork bomb" est tout plein de bonne intention). Linux c'est tout le contraire. Avec Windows, ses assistants sécurité, etc ... et on est dans un monde meilleur avec plein de programmes plein de bonnes intentions et qui veillent sur nous pauvre abrutis d'utilisateur (dormez tranquille on veille sur vous). Mais dans la pratique ce modèle suxe grave de chez grave. Le comparatif Windows/Linux|Unix nous en fait la démonstration tous les jours.
Les problèmes de sécurité c'est compriqué et il faut toujours y réfléchir sur plusieurs niveaux. Par exemple un truc qui détecte si l'ActiveX bidule dans la page qu'affiche IE supprime un fichier ou fait un "fork bomb", c'est bien. Mais pas d'ActiveX dans les page web c'est beaucoup mieux. C'est exactement ce que fait FireFox (pas d'ActiveX). Il n'y a pas un truc au-dessus de Firefox pour le limiter et ce pour le bien de l'utilisateur. Firefox se limite de lui même. Si tu as confiance en Firefox (et je pense que tu devrais) alors utilise le et pleinement. Si tu n'as pas confiance en IE (et je pense que tu ne devrais pas) alors n'utilise pas IE. Qu'il y est ou non un "big brother" qui contrôle ce que fait IE ne change rien.
T'as jamais pensé qu'il faudrait un système pour contrôler ce qui contrôle ce que fait l'utilisateur ?
[^] # Re: public
Posté par Gilles G. . Évalué à 2.
Je ne suis pas informaticien...
[^] # Re: public
Posté par ola . Évalué à 2.
mouarf, pas mal comme politique de secu : une fois que tu t'es rendu compte que tout est en vrac par terre, et ben tu notes sur un post it "ne pas faire ca" et tu le colles sur l'ecran.
[^] # Re: public
Posté par GPH (site web personnel) . Évalué à 4.
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
Où est la politique de sécurité quand on est dans l'hypothèse de personnes qui lancent tout et n'importe quoi comme programme ?
Et c'est une politique de sécurité de détecter les "fork bomb" ?
Le gus qui download tout et n'importe peut aussi downloader des programmes qui supprimer des fichiers. Et là les inconvénient non rien à voir un reboote car un fork bomb fait swapper la bécane comme une dingue.
Mais dors tranquille, t'as un truc pour détecter les "fork bomb". Bonne nuit.
[^] # Re: public
Posté par Thomas Douillard . Évalué à 4.
Que ce soit un bug dans un programme ou autre chose, c'est pas le problème, je vois vraiment pas en quoi ça regarde l'utilisateur si il y a une solution simple et qui ne le fait jamais chier en pratique, genre un ulimit.
[^] # Re: public
Posté par IsNotGood . Évalué à 1.
Probablement jamais.
> je me fiche que ce soit une fork bidou ou je ne sais quoi, je veux mon boulot"
Si t'es un admin, tu interdis l'excécution de programme qui sont dans des répertoires où l'utilisateur peut écrire (donc l'installer). Ainsi l'utilisateur ne peut utiliser que des programmes "approuvé" par l'admin. Et si l'admin fait bien son boulot, il ne met pas de programmes avec des "fork bomb", il ne met que des programme de confiance.
> Que ce soit un bug dans un programme ou autre chose, c'est pas le problème, je vois vraiment pas en quoi ça regarde l'utilisateur si il y a une solution simple et qui ne le fait jamais chier en pratique, genre un ulimit.
Solution qui n'empêche pas l'utilisateur d'installer un programme qui fait une bête "rm -r -f $HOME" ou d'envoyer tous ses documents confidentiel sur le web.
Tu parles d'une politique de sécurité...
J'ai d'autres priorités.
Ne me dit pas que tu es administrateur s'il te plait.
[^] # Re: public
Posté par briaeros007 . Évalué à 2.
Ps juste comme ca, la seule machine vraiment sur, c'est celle qui est éteinte ;) (et encore ... )
[^] # Re: public
Posté par Calvin0c7 . Évalué à 4.
Donc si tu bananes ta machine en exécutant un code moisi, tu prendras ton coup de pied au cul de la part de l'admin et tu l'auras mérité.
Si tu lui répond qu'il n'y avait qu'à avoir une limitation pour empêcher tes conneries de plomber la mémoire c'est qu'il faut changer de métier.
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
Oui et notamment car je suis aussi développeur donc je comprend les besoins/attendes des développeurs. Mais que le developpeur ne me demande pas le mot de passe root si la bécane est utilisée par plusieurs personnes. Dans ce cas c'est systématiquement un non ferme et définitif. Les sudo sont accordés au compte goutte.
Si le développeur est tout seul sur la bécane, il fait ce qu'il veut et je m'en fout royalement (du moins en tant qu'administrateur). C'est ses affaires.
Mieux, si une développeur est seul sur une bécane et qu'il me demande plus de contrôle alors que j'administre cette bécane, je fais un backup complet et je lui accorde le compte root sans le moindre soucis après avoir viré tous les autres comptes (question de confidentialité). Mais après il se demmerde, je ne veux plus entendre parler de cette bécane. Lorsqu'il a terminé, je restaure mon backup.
NB : C'est vrai que les développeurs se débrouillent bien avec les OS et ont peu besoin d'"assistance". Par contre il faut un peu les responsabiliser. Le développement n'est pas un jeu.
[^] # Re: public
Posté par Thomas Douillard . Évalué à 1.
Deuxièment je vais me permettre de reprendre à mon compte une : maxime "peut-on mettre un (bon) admin derrière chaque machine ?"
[^] # Re: public
Posté par ola . Évalué à 4.
Bienvenue dans le monde reel...
Tu sais, celui ou il faut apporter des solutions les plus satisfaisantes possibles a des problemes theoriquement insolubles...
Oui les utilisateurs lancent tout et n'importe quoi.
Est ce que c'est une raison pour autoriser n'importer quoi alors qu'on a des moyens simples de detecter un probleme evident (j'aimerais bien savoir quelle application a besoin de 16000 forks...)
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
Si ça arrive, t'as vite fait de t'en rendre compte et ce n'est pas ulimit qui va empêcher l'exploitation de faille de sécurité donc les conséquences n'ont rien à voir avec un petit reboot.
Occupons nous de l'accessoire, le principal attendra...
[^] # Re: public
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: public
Posté par ola . Évalué à 3.
mais j'ai l'impression que ce que t'as pas compris, c'est que, justement, le boulot de l'admin, ben c'est que ce genre de choses ca arrive pas.
Ne serait ce parce que, de base, si les gens faisaient ce qu'ils doivent faire et ne faisaient pas ce qu'ils ne doivent pas faire, le metier d'admin n'existerait pas.
ce n'est pas ulimit qui va empêcher l'exploitation de faille de sécurité
ok, alors on va prendre le probleme clairement:
Qu'est ce que tu gagnes a utiliser ulimit? la garantie qu'un fork bomb ne marchera pas.
Qu'est ce que tu perds a utiliser ulimit? rien.
Qu'est ce que tu gagnes a ne pas utiliser ulimit? rien.
Qu'est ce que tu perds a ne pas utiliser ulimit? la garantie qu'un fork bomb ne marchera pas.
Bon courage pour justifier ton choix le jour ou un pb arrivera.
Occupons nous de l'accessoire, le principal attendra...
Chez moi, on s'occupe du principal. et aussi de l'accessoire.
Et on appelle ca "faire son boulot".
[^] # Re: public
Posté par IsNotGood . Évalué à 3.
Rappel : on parle d'un usage desktop et non serveur.
Si tu veux éviter les fork bomb de façon significative, il faut que tu limites à 50 ou 100 processus (voirs 150). Au dessus, un fork bomb qui lance des processus qui bouffent du cpu te rend la bécane quasi inutilisable => donc reboot.
Hors 50 ou 100 processus pour un utilisateur ce n'est pas exceptionnel. Donc ce qu'on perd en utilisant ulimit pour limité le nombre de processus (et en le configurant pour qu'il soit utile et non qu'il donne seulement une impression de sécurité) c'est la possibilité d'utiliser sa bécane de façon un poil poussé (pas la peine de faire des choses extraordinaires).
Et tout ça pour quoi ? Pour éviter un reboot tous les 36 du mois. Je trouve qu'il est 1000 plus pertinant d'installer des ondulateurs. Il y a 1000 fois plus de reboot car l'alimentation tombe en panne qu'à cause d'un fork bomb. Je me trompe ? Je ne crois pas.
Question : Il est à combien ton ulimit ?
À moins de 100 ? J'en doute.
[^] # Re: public
Posté par ola . Évalué à -1.
[^] # Re: public
Posté par IsNotGood . Évalué à 4.
> Qu'est ce que tu perds a utiliser ulimit? rien.
J'ai répondu à ça plus haut.
> mais j'ai l'impression que ce que t'as pas compris, c'est que, justement, le boulot de l'admin, ben c'est que ce genre de choses ca arrive pas.
Et ça t'est arrivé combien de fois sur des postes desktop ?
0 ou 1 fois ?
Et les conséquences ? Un reboot. Mais tu as vu combien de reboot "sauvage" (non désiré), de reset à cause d'un nouveau noyau qui a un driver qui sucks, ou à cause d'un problème hardware (une carte mal insérée, etc) ou de coupure de courant ? 1000 et peut-être probablement plus.
Si tu es préoccupé par les reboots "sauvage", je te comprend. Mais il y bien autres chose a faire avant de regarder du côté d'ulimit. Et tu configures ulimit pour que les fork bomb soient anodins, tu seras emmerdé par quelques utilisateurs qui font une utilisation un poil poussé de linux. Ils vont perdre du temps, tu vas perdre du temps pour finalement virer ou du moins atténué ulimit (ce qui probablement ne te mettra plus à l'apris d'un fork bomb). Et ça pour quoi ? Pour éviter au mieux 0,1 % des reboots "sauvages". Et 0,1 %, je suis gentil, ça doit être beaucoup moins.
Si on te paye pour ça, si on te paye pour être préoccupé par ça au lieu de t'investir dans d'autres domaines qui impactent significativement le fonctionnement de l'entreprise, alors t'es dans une boite blindée de tune et pas soucieuse du rendement, de la plus-value, de ses employés. Un conseil : restes y.
[^] # Re: public
Posté par JaguarWan . Évalué à 7.
Ton OS de rêve existe déjà, ça s'appelle DOS (et un peu d'assembleur).
jaguarwan@selenyx:~$ cat /etc/limits
root -
jaguarwan L3U128
jaguarwan@selenyx:~$ cat /etc/slackware-version
Slackware 11.0.0
jaguarwan@selenyx:~$
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
Tu n'as pas compris ce que je dis ou je me suis mal exprimé.
> halte à la tyrannie de l'OS qui nous prive de nos ressources
C'est faux, c'est lui qui nous permet d'accéder aux ressources.
> abolissons la mémoire protégée
Jamais dit ça. La mémoire protégée permet d'avoir plusieur processus en même temps et c'est un moyen pour protégé l'OS (j'ai dit : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK")
> abattons le scheduler
Jamais dit une telle absurditée. Le scheduler permet d'utiliser les ressources dans un contexte multiprocessus. Utilises Windows 3.1 et tu vas vite comprendre.
Le scheduler n'est pas un truc pour limiter l'utilisation des ressources, c'est l'inverse.
> je veux pouvoir bouffer tout le processeur quand ça me chante
Pareil pour moi.
> et écrire où je veux en mémoire !
Je veux écrire en mémoire. Mais le lieu m'importe peu.
Bof. M'enfin tu peux toujours avec le compte root et /dev/mem.
> jaguarwan@selenyx:~$ cat /etc/slackware-version
Installes OpenBSD si tu veux frimer.
[^] # Re: public
Posté par JaguarWan . Évalué à 2.
Je suis sous Slack et je limite *volontairement* le nombre de processus pour mon compte utilisateur.
Apparemment, le second degré de mon commentaire précédent n'était pas assez apparent.
Pour moi, limiter le nombre de processus par défaut est au même titre que l'utilisation de la mémoire protégée, ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur/des performances brutes mais permettant une sécurité, une stabilité et un confort d'utilisation compensant plus que largement son coût.
Y a des gens qui ont le même dédain que toi pour la limitation du nombre de processus, mais pour la mémoire protégée/le multitâche préemptif; et ce avec des raisons assez voisines de "ces trucs limitent ma liberté, si ça plante/freeze c'est de la faute du user pour lancer un truc malveillant/codé avec les pieds".
Laisser le nombre de processus illimité est un DoS potentiel, et il n'y aucune raison valable de ne pas combler cette faille.
En effet, même si on est un brave utilisateur qui ne lance jamais de programme malveillant, on n'est jamais à l'abri d'un programme tout à fait légitime, codé par des gens respectable, mais qui comporte un bug vicieux. Si ça arrive, chez moi le programme se fera tuer froidement par le noyau, mais toi tu rebooteras ta machine.
[^] # Re: public
Posté par IsNotGood . Évalué à 3.
Désolé.
> Pour moi, limiter le nombre de processus par défaut est au même titre que l'utilisation de la mémoire protégée, ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur/des performances brutes mais permettant une sécurité, une stabilité et un confort d'utilisation compensant plus que largement son coût.
Non. Limiter le nombre de processus n'est pas la même chose que la mémoire protégée. Ce n'est pas parceque tu as de la mémoire protégée que tu ne peut pas faire un "malloc(4Go)" qui fait swapper ta bécane comme un fou voire aboutis à des "kill ... Out of memory" par le noyau.
La mémoire protégée c'est pour avoir plusieurs processus à la fois, ça ne limite pas l'utilisateur dans ce qu'il peut faire.
Par contre ulimit, comme son nom l'indique, limit l'utilisateur dans ce qu'il peut faire.
> ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur
Je ne te suis absolument pas.
En quoi du multitâche préemtif est une mesure restrictive ?
En quoi ça limite la liberté de l'utilisateur ?
Franchement, je ne vois pas du tout.
Si tu veux bouffer 100% du cpu et laisser 0% au autre, tu peux utiliser chrt (faut être root, sinon tu peux aussi faire un "chmod +s" ; c'est vivement déconseillé).
Le multitache préemtif n'est pas pour limiter les utilisateurs, c'est là encore le contraire. C'est pour permettre à plusieurs personne/programme de bosser en même temps. Au-lui qu'un programme attende la fin du programme en cours, il a la liberté de s'exécuter tout de suite.
Si tu as windows 3.1, il ne peut y avoir qu'une personne/programme à la fois. Si tu as un système multitache, t'as plus de liberté et non moins. Si plusieurs personnent utilisent le même PC en même temps, les ressources du PC sont plus utilisées et non moins utilisées.
Bref, je ne te comprend absolument pas.
> Laisser le nombre de processus illimité est un DoS potentiel, et il n'y aucune raison valable de ne pas combler cette faille.
Mais là tu parles d'un serveur. Un programme qui n'est pas accessible de l'extérieur ne peut pas être attaqué.
Au début du thread il y avait :
- "En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse..."
C'est un dire pour des distributions qui ne sont pas orientées serveurs mais orientées desktop (ça ce discute).
Puis je le répète pour la millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK".
> Je suis sous Slack et je limite *volontairement* le nombre de processus pour mon compte utilisateur.
TU te limites comme bon te semble, j'en ai rien à foutre. Mais si c'est un autre qui le fait pour toi ? Ça te plait ?
Si un jour le programme bidule ne se lance pas car il utiliser 201 thread et qu'un autre a limité le nombre de thread par process à 200 pour soit disant ton bien, t'es content ?
> Y a des gens qui ont le même dédain que toi pour la limitation du nombre de processus
Je n'ai aucun dédain pour ulimit, etc. C'est un truc indispensable pour un serveur. Mais limiter ce que fait l'utilisateur avec le prétexte que c'est pour son bien alors qu'on est dans un contexte desktop est de la connerie. S'il a 4 Go de mémoire et veut tout utiliser, c'est ses oignons, je ne vois pas pourquoi on va le limiter, et si ça fait ramer sa bécane au point de la rendre inutilisable, ça n'emmerde que lui. Je suis persuadé qu'il ne recommencera pas et que pour ce type de problème il est ridicule, pour ne pas dire néfaste, de développer une solution.
> En effet, même si on est un brave utilisateur qui ne lance jamais de programme malveillant, on n'est jamais à l'abri d'un programme tout à fait légitime, codé par des gens respectable, mais qui comporte un bug vicieux.
Si tu crois qu'un jour ou pourra éviter les effets de bord des programmes codés avec le pied, tu te trompes lourdement.
> Si ça arrive, chez moi le programme se fera tuer froidement par le noyau, mais toi tu rebooteras ta machine.
Oui, et je ne relance plus ce programme. Si ma bécane sert aussi de serveur, alors j'utilise ulimit. S'il n'y a que moi, alors je n'utilise pas ulimit.
Puis là encore on est dans du hors sujet. Limite toi tant que tu veux, je m'en fous. Mais qu'on te limite, tu serais d'accord ?
[^] # Re: public
Posté par ola . Évalué à 3.
ce que t'es en train de dire, c'est que ulimit empeche l'utilisateur de lancer plus de processus que sa machine peut en faire tourner?
Donc en somme, ulimit "empecherait" l'utilisateur de faire quelque chose qui est par definition impossible a faire?
Mais là tu parles d'un serveur. Un programme qui n'est pas accessible de l'extérieur ne peut pas être attaqué.
non.
une machine par terre, c'est une machine qui ne peut pas etre utilisee.
Et ca c'est un deni de service, que la machine soit un serveur; une machine de dev ou une machine de bureautique.
Si tu crois qu'un jour ou pourra éviter les effets de bord des programmes codés avec le pied, tu te trompes lourdement.
effectivement.
Maintenant, est ce une raison pour ne pas eviter les effets de bords que tu pourrais eviter?
Tu parlais de "simple reboot" tout a l'heure.
ok, alors supposons que la machine en question soit, par exemple, une machine dans une fac par exemple.
Tu sais le genre salle libre acces pour etudiant en informatique du deug au dess (oui, bon master, on s'en fout c'est pareil).
Un mec du dess a un calcul relativement important qui tourne sur la machine dans un screen, par ex.
un abruti lance un fork bomb. Ah bah, ya qu'a rebooter.
ben ouais, mais la tu met un mec dans la merde : DoS (ah ben tu vois, on est dans un contexte desktop, et pourtant...).
Surtout qu'il peut potentiellement mettre beacuoup de temps a s'en rendre compte.
Il avait qu'a faire gaffe?
Non. T'avais qu'a mettre un ulimit, ca aurait prevenu le probleme plutot que de dire "yavait qu'a pas".
Autre situation : t'es connecte a distance sur la machine et un connard la reboot.
Ben toi t'es comme un con chez toi a attendre que la machine ait reboote.
Ah ouais, mais elle a reboote la machine, partition mal demontee, fsck gueule au boot et demande le pass root pour checker le fs.
Ben ouais, mais on est vendredi, 17h38, l'admin vient de partir en we, t'attendra lundi mon coco... Vecu par moi meme, et plusieurs fois.
DoS, encore une fois. Et toujours dans un contexte desktop, tu noteras.
T'avais qu'a ... ?
non, toi t'avais qu'a mettre un ulimit.
Le boulot c'est justement de proteger les gens d'eux memes. Tu penses que c'est pas possible? ben changes de boulot, mon con, qu'est ce que tu veux que je te dise, on va pas embaucher un mec pour nous expliquer qu'il peut pas faire ce qu'il est cense faire.
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
Tu l'as dit, c'est un abruti. Fout lui un coup pied au cul bien senti.
De plus, s'il est dans la salle d'info avec de mauvaises intentions, il n'a pas besoin de faire un fork bomb pour foutre le bordel. Il débranche une prise de courrant, une prise réseau, une prise clavier, pique 1 seconde la souris pour cliquer sur "fermeture" ou fait <alt><F4>, etc...
Le truc le plus "marrant" c'est lorsqu'un utilisateur n'a plus les yeux sur ça session (il discute, il est allé pisser, etc), c'est de changer son mot de passe. Même les connards y pensent.
> on est dans un contexte desktop, et pourtant.
Pas vraiment puisqu'il peut y avoir plusieurs utilisateurs (de plus simultanément) sur une même bécane. La bécane devient un serveur de session.
Enfin, les salle informatiques sont des lieux où on fédère. En un sens ça doit quasiment être considéré comme des serveurs. Or pour les serveurs je n'ai jamais dit qu'ulimit était inutile.
> Autre situation : t'es connecte a distance sur la machine et un connard la reboot.
C'est un connard. Tu peux interdire la commande reboot, même si c'est un connard, il va penser à débrancher la prise ou appuis sur le bouton reset. Même un connard profond peut penser ça et ulimit est en rien une solution à ce problème.
> Ben ouais, mais on est vendredi, 17h38, l'admin vient de partir en we, t'attendra lundi mon coco... Vecu par moi meme, et plusieurs fois.
Et oui, la vie est dure. Mais ulimit ne change rien dans ce que tu as dit et t'en es la preuve puisque tu utilises ulimit (si tu l'utilises, ce que maintenant j'en doute).
> Non. T'avais qu'a mettre un ulimit
La solution magique mais que ces abrutis de distributeur avec tous leurs experts ne mettent pas en oeuvre.
Oui, oui, oui, oui. C'est celà.
> DoS, encore une fois.
Pour info, en passant.
Si tu configure ulimit pour qu'il soit efficace il faut le configure à 100 voir 150 processus grand maximum. Un utilisateur peut légitiment atteindre cette limite. Dans ce cas c'est aussi un denial of service. Oui oui et avec presque les même conséquences.
Certe, ce n'est pas un denial of service attack. Mais pour l'utilisateur c'est un denial of service.
> on va pas embaucher un mec pour nous expliquer qu'il peut pas faire ce qu'il est cense faire.
C'est clair que toi vu le niveau élevé de tes analyses (même pas foutu d'imaginer ce que peut faire un connard), je ne risque pas de t'embaucher.
[^] # Re: public
Posté par ola . Évalué à 2.
et ca servira a quoi?
le mal est fait...
les cu
De plus, s'il est dans la salle d'info avec de mauvaises intentions,
il a pas forcmeent de mauvaises intentions... il peut faire une bourde comme ca arrive...
Pas vraiment puisqu'il peut y avoir plusieurs utilisateurs (de plus simultanément) sur une même bécane. La bécane devient un serveur de session.
tu chipotes la...
Même un connard profond peut penser ça et ulimit est en rien une solution à ce problème.
reboot suite a un probleme qui aurait ete evite par ulimit, j'entends...
[^] # Re: public
Posté par B16F4RV4RD1N . Évalué à 5.
Je serais plutôt tenté de dire que c'est à l'utilisateur aguerri qui aurait besoin de mettre des valeurs illimitées de faire la démarche pour passer outre cela. Cela serait très simple pour lui, concernerait sans doute 1% des utilisateurs linux, et protègerait 99% des autres.
Tout ce qui peut mettre en péril la stabilité d'un OS par un processus utilisateur devrait être évité, quel que soit le moyen utilisé, que cela soit par le réseau, ou en local.
Sinon on peut dire également que les distribs linux pourraient laisser le port telnet d'ouvert, après tout l'admin de la machine devrait vérifier lui-même avant de la mettre sur le réseau que celui -ci n'est pas ouvert et activé.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: public
Posté par Thomas Douillard . Évalué à 3.
Donc dans le cas normal la limite n'a aucune incidence. Si vraiment l'utilisateur à besoin de la dépasser, à priori c'est pas un simple utilisateur et il sait ce qu'il fait. Ou il prévient les gens qui vont utiliser son soft.
[^] # Re: public
Posté par IsNotGood . Évalué à 3.
Quelles valeurs ?
Par exemple pour la mémoire, on limite à 1Go ?
Et si l'utilisateur lance un programme qui utilise de façon tout à fait légitime 1Go + 1 octet. On fait quoi ?
Quelles valeur pour la consommation cpu par un processus ?
24 h? Ça semble fort raisonnable.
Et si l'utilisateur code une grosse vidéo en 1920x1080 et que ça prend 25 h ? Ben il va virer ulimit et recommencer. Il aura perdu au moins une journée.
Quelles valeur pour la consommation de disque dur ?
Ben oui, il peut y avoir un programme malintentionné qui ne fait que saturer le disque dur. 10 Go ? Trop peu en cette époque de vidéo. 100 Go ? Pourquoi pas. Mais bon, on active quelque chose qu'au bout de 100 Go !!!!
Puis un programme malintentionné n'a pas besoin de 24 h pour faire des dégâts et n'a pas besoin de 1 Go de mémoire vive pour faire des dégâts et n'a pas besoin de 100 Go d'espace disque pour faire des dégâts et n'a pas besoin de se forker 1000 fois pour faire des dégâts.
Donc ulimit comme outil de sécurité c'est assez limité :-)
> pour éviter soit comme il a été dit précédemment qu'une faille de sécu dans un prg permette de lancer un tel fork bomb
C'est un programme type serveur, donc il faut corriger le programme. Et si c'est pour l'aspect DOS, ça ne change pas grand chose car ulimit aura killé le serveur donc on a aussi un DOS.
Je répète pour le 10 millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK". C'est aussi valable pour un programme. Si un serveur a l'intelligence d'appeler ulimit, capability, setuid(), etc. Très bien.
Qu'un autre programme passe par là au nom du "bien être de l'utilisateur" et se dise "bizarre, ce processus me semble consommer de façon illégitime trop de mémoire, donc je vais le tuer", pas d'accord. Pas d'accord dans un contexte Desktop.
> soit qu'une machine plus ou moins publique soit plantée à cause de cela
Une machine public est une sorte de serveur. Elle est multi-utilisateur même si ce n'est pas simultanement. Il est claire que pour ce type de machine, il faut quelque précautions (quota, etc... cf les cyber café par exemple). Mais faut-il faire peser ses contraintes pour un utilisateur qui installe une Ubuntu pour seul usage et peut-être celui de sa copine ou son copin ?
Je ne crois pas car ça risque d'être plus une source d'emmerde qu'autre chose. Et s'il subit un fock bomb ? Ben il reboote et voilà. Si ça lui arrive 1 fois en 3 ans c'est déjà remarquable. Je ne crois pas qu'il faut s'emmerder avec ça.
C'est claire que si on considère que ces trucs (limiter le nombre de fork, etc...) marche nickel, n'ont pas d'effet de bord, etc, il est claire que quand je dis que c'est de la connerie, je passe pour un abruti profond.
Mais ces systèmes ont des effets de bord. Voir Windows qui a tout un tas de truc dans ce goût. Mais comme ils ont des effets de bords, Windows donne à l'utilisateur la possibilité de les désactiver. Et c'est ce que fait la majorité des utilisateurs, ce qui donc enlève l'intérêt de ces "trucs".
> Je serais plutôt tenté de dire que c'est à l'utilisateur aguerri qui aurait besoin de mettre des valeurs illimitées
Il faut peser le pour et le contre. Mettre des limites est contraignant (par définition). Si c'est seulement pour eviter qu'un utilisateur chez lui reboote ça bécane 1 fois tous les 3 ans car un programme a déconné, je trouve que c'est trop d'inconvénient et il y a aussi le risque que finalement l'utilisateur désactive tout ce qui le limite.
Si c'est sur un serveur qui héberge une centaine de site web professionnel avec des informations confidentiel, etc, c'est claire que même un reboote imprévu n'est pas tolérable même si c'est tout les trois ans et que l'utilisation de ulimit doit être vivement encouragée.
> protègerait 99% des autres.
Protéger de quoi ?
D'un reboot tout les trois ans ?
Un programme mal intentionné n'a pas besoin de se fock 1000 fois pour faire des dégâts.
> Sinon on peut dire également que les distribs linux pourraient laisser le port telnet d'ouvert
Tu parles de donner la possibilité à des personnes externes d'utiliser ta bécane, ça n'a rien à voir. On parle d'utilisateur légitime qui lance un programme.
[^] # Re: public
Posté par briaeros007 . Évalué à 2.
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
> un programme qui consomme plus de mémoire que le systeme supporte se fait oom killed sans la moindre once de pitié
S'il n'y a pas oom, c'est pire. Lors qu'on arrive à la limite hardware, deux solutions :
- un malloc/mmap/etc echoue et le programme s'arrête "gentillement"
- le programme est killer -9
> ce qui n'existe pas pour les processus
Avec ulimit, c'est presque la même chose :
- un malloc/etc echoue et le programme s'arrête "gentillement"
- le programme est killer -9 si par exemple s'il fait des appels récursives de fonction (la pile augmente).
[^] # Re: public
Posté par B16F4RV4RD1N . Évalué à 2.
c'est vrai. Et c'est bien entendu effectivement ennuyeux si cela limite par ailleurs l'utilisation de l'ordinateur (comme dans les cas que tu as cités, calcul qui dure longtemps etc).
Mais comment font les bsd alors ? Je présume que cela ne vient pas interférer avec l'utilisateur dans son utilisateur quotidienne, et c'est efficace puisque cela a pu éviter de planter la machine. Je pense qu'au delà d'une certaine charge, on sort des limites d'utilisation normale d'une machine. Un calcul qui charge trop la machine au point de la faire plier, ou un encodage de musique / film qui monte la charge (load average) à 50 par exemple, cela ne me semble pas spécialement un programme bien conçu :)
Pour info, sur le serveur de messagerie à mon boulot, avec un vieux mailscanner cela montait des fois à 12, et cela devenait difficilement utilisable (provoquait des problèmes d'écriture en tant que serveur de fichier, mais avec une version plus récente de mailscanner, c'est redevenu normal).
Sous freebsd, en faisant le fork bomb, le "load average" est quand même monté à plus de 140 ! :)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: public
Posté par IsNotGood . Évalué à 3.
On est en pleine parano. Les spécialistes sécurités estiment que ulimit est sans intérêt sauf pour les serveurs (partage des ressources notamment comme c'est fait avec les quotas). D'où les distributions qui n'ont pas ulimit configuré par défaut ou alors avec des marges telles qu'on peut se demander si on utilise ulimit. C'est trois rien à faire de configurer ulimit, ça existe depuis des lustres, mais les distributions ne le configure pas, les spécialistes sécurités des distributions ne voit pas l'intérêt de son utilisation par défaut. Ulimit n'a jamais empêché d'utiliser une faille de sécurité.
Mais les gens veulent du ulimit. Qu'on leur en donne.
L'effet placébo marche, j'en ai la preuve.
> Sous freebsd, en faisant le fork bomb, le "load average" est quand même monté à plus de 140 ! :)
À 140 d'upload la bécane est inutilisation. Si je suis malintentionné, je peux faire un truc qui fait monter ton upload à 140 et que ton "fork bomb detector" laissera en paix.
Si c'est 140 alors d'un fork bomb c'est rapide, on peut estique que freebsd me permet au moins de lancer 200 processus. L'argement de quoi rendre l'OS inutilisable. Si ça détecte la vitesse des forcks, je peux au moins faire un fork par second en toute discretion. La seule différence, c'est qu'il me faudra 200 seconde (un peu plus de 3 minutes) pour rendre ta bécane inutilisable.
J'espère que tu te sens plus en "sécurité" maintenant avec ton "fork bomb detector".
[^] # Re: public
Posté par B16F4RV4RD1N . Évalué à 2.
hmm, pourrais-tu le faire en remettant les lettres à leur place ? Parfois c'est un peu dur à suivre l'ensemble de ce dernier message. C'est ta langue qui a forké ?
chiche ? Moi je veux bien voir.
peut-être. Je ne sais pas. En fait pour moi un système sécurisé c'est un système sur lequel on pourrait mettre un compte shell de base ouvert à tout le monde, et qui ne pourrait pas être compromis de cette manière (ni par les autres ports d'ouvert, http, ftp etc bien entendu), en encore moins planté à cause du shell.
Il y avait eu ce test :
http://financialcryptography.com/mt/archives/000674.html
On attend donc la même chose avec un openbsd, et ton "truc qui fait monter ton upload à 140 et que ton "fork bomb detector" laissera en paix.".
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: public
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
> À 140 d'upload la bécane est inutilisation.
FAUX, même à 700 de charge, et plus encore, une machine peut être parfaitement utilisable.
D'ailleurs, les serveurs de kernel.org sont à 400 de charge et pourtant ils fonctionnent...
Tu peux tester toi même. tu te mets un ulimit à 1000.
Tu lances ":(){ :|:& };:" dans un shell, et si la commande ne se fait pas tuer de suite, elle plafonnera à 1000 process, ta charge montera à 800 sans problème, mais X et le reste de tes applis tourneront sans problème.
> Je peux faire un truc qui fait monter ton upload à 140 et que ton "fork bomb detector" laissera en paix.
Impossible.
Par définition, la charge (load average) se définit par le nombre de processus en attente d'utiliser le CPU. Donc le load ne peut pas dépasser le nombre de processus maximum autorisé par ulimit et surtout pas le nombre de processus de tout le système.
Ensuite, si on se place dans ton contexte de marchine desktop, tu es incohérent avec toi même. Pourquoi dire OUI à la protection mémoire et NON à ulimit. Pour les même raisons que tu invoques contre ulimit, la protection mémoire ne sert à rien. Si tu lance un programme qui fait planter les autres, ben t'es vraiment le roi des cons si tu persites a lancer le même programme...
Pourquoi dire OUI à la protection des fichiers. Si tu es trop con pour effacer tes fichiers, il n'y a aucune raison que le système de t'en empéche. Tu serais encore le roi des cons pour faire 2 fois la même erreur...
Enfin, tu dis "ulimit comme outil de sécurité c'est assez limité"
Oui, comme tout les outil de sécurité, et ce n'est pas avec une seule brique que l'on construit un mur.
[^] # Re: public
Posté par briaeros007 . Évalué à 7.
Si tu commence a swapper comme un bourrin, oki ta machine est vraiment plus lente, ca c'est sur ... mais elle marche encore, jusqu'a ce que le programme soit oom, où la elle retrouve son état 'normal'
Maintenant dans le cadre d'un fork bomb, avec ton ulimit trop haut, ta machine est pas plus lente ... elle marche plus !
Toute la table de processus est prise par tes fork bomb , et si tu arrive trop tard (cad 3 sec apres le lancement) tu ne pourras strictement plus rien faire. Meme pas lancé un kill, car le temps qu'une place se libere dans la table des processus , il sera repris par un autre fils.
Fait le test, entre un programme qui fait une alloc récursive , et un programme qui fait un fork récursif ...
(bien entendu rien n'empeche de combiner les deux).
Ensuite attend 30 min, et dis moi quelle machine tu peux encore réussir à administrer, et quel machine tu ne peux pas.
Le plus drole c'est que c'est toi qui prone l'interdiction pur et dur de compilation/execution de binaire non approuvé par l'administration , mais la mise en place d'un limits.conf par défaut dans les distribs, ah ca non surtout pas...
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
Désolé, j'avais mal compris. J'étais dans le cas de l'utilisation d'ulimit pour limité l'utilisation de la mémoire.
> Toute la table de processus est prise par tes fork bomb , et si tu arrive trop tard (cad 3 sec apres le lancement) tu ne pourras strictement plus rien faire. Meme pas lancé un kill, car le temps qu'une place se libere dans la table des processus , il sera repris par un autre fils.
Certe, il faut rebooter. La grande affaire. Oui, c'est une grande affaire pour un serveur. Mais pour un serveur je n'ai jamais dit que ulimit n'avait pas de sens, bien au contraire.
> Le plus drole c'est que c'est toi qui prone l'interdiction pur et dur de compilation/execution de binaire non approuvé par l'administration ,
J'ai dit ça pour le cas d'une bécane qui est adminitrée par un administrateur. On n'est plus dans le cas de monsieur tout le monde qui installe une Ubuntu pour son usage personnel.
Ceci pour des raisons de sécurité et notamment de confidentialité. Dans une entreprise (puisque la bécane est administrée) c'est IMPORTANT ! C'est 8 millions de fois plus important que le reboot d'une bécane (qui de plus n'est pas un serveur) tous les 3 ans car on n'a pas configuré ulimit.
Avec un programme malintentionné que l'utilisateur a lancé par mégarde, depuis l'extérieur tu peux avoir un accès à la bécane qui est dans l'entreprise ! Oui oui !
Ce programme peut aussi s'amuser à envoyer des documents de l'utilisateur (en fait, de l'entreprise) sur internet !
C"est 80 milliard de milliard de fois plus grave qu'un improbable reboote d'une bécane qui n'est pas un serveur.
Et pourtant je ne suis pas si tyranique que ça. Ça dépend des données sur la bécane, des accès réseaux qu'elle a etc... Mais si c'est la secrétaire du boss par exemple, je vais être assez intransigeant.
Ça montre a quel point j'en ai rien à foutre d'ulimit pour un desktop.
Ulimit est vachement bien, même pour un desktop, dans un cas que je connais : pour gpg. Aujourd'hui beaucoup de distributions *autorisent* (et non restraindre ; car par défaut sur Linux on ne peut pas le faire) via pam/ulimit 32 ko de mémoire verrouillable (c'est-à-dire non swappable). C'est utilisé par gpg pour que le mot de passe qui est tapé ne se retrouve pas dans le swap. C'est une excellente idée. Ça devrait aussi être utilisé pas ssh, etc...
> mais la mise en place d'un limits.conf par défaut dans les distribs, ah ca non surtout pas...
Qu'un admin le fasse dans son entreprise, pourquoi pas, c'est rapide. Pour une distribution qui va être utilisé par une personne (c'est-à-dire que ce n'est pas un serveur) je n'en vois pas l'intérêt. Et le seul intérêt jusqu'à maintenant avancé est d'éviter un reboot. Ça n'empêche pas l'exploitation de faille de récurité ni rien, ça permet d'éviter un reboot de plus fort improbable. Ici il y a des gens qui parle d'"expérience" avec un "fork bomb", mais en général le "fork bomb" ils se le sont fait eux même, pour le "fun".
Tu parles d'une grande affaire...
Pour le desktop, il y a bien d'autre domaine a améliorer avant de s'occuper d'ulimit. Par exemple OOo. Dans un document OOo on peut mettre des macro qui écrivent sur le disque, etc...
On pourrait, par exemple, dans le cas où le document est ouvert depuis un navigateur ou un client mail (donc en général quand le document vient d'internet), qui lance OOo, avoir une option du type "sandbox" où toutes les lectures/écriture du document y seront faites.
Ça c'est un plus en sécurité et je serait ravis que toutes les distributions l'implémente. De plus ça ne limite pas l'utilisateur. Il peut ouvrir les documents, même ceux compliqué qui nécessite l'écrite sur un périphérique de stockage.
Un autre domaine d'amélioration dans le desktop, est la "généralisation" de la crypto pour les clées USB qu'on ballade partout. Ça implique que toutes les distributions se mettent d'accord sur un standard trivial à utiliser.
Ça aussi c'est un vrai plus. Si t'oublies ta clée chez un pote ou dans un lieu public, et qu'il y avait des documents importants dessus, ça peut faire une différence énorme et qui n'a rien à voir avec un reboot.
[^] # Re: public
Posté par briaeros007 . Évalué à 2.
dans le cadre d'une machine vendu au supermarché avec mandriva/ubuntu: un ulimit/limits.conf/détection des fork : oui, ca peut etre utile, style il vas sur linuxfr et 'tiens j'ai fait ... et ca a planté la machine'. Et la le gars veut essayer et paf :P
Dans le cadre d'une machine administrée (entreprise), que ce soit par défaut ou pas, c'est à l'administrateur de décider suivant le besoin de ses utilisateurs itou ;)
Quand aux améliorations avec OOo , ben c'est autre chose. On peut déja faire ca dans les distribs 'grand public', donc pourquoi pas ? et de l'autre coté rien n'empeche de continuer de bosser sur OOo ;)
<je ne parle que des distribs 'grands public'. Les cas plus spécifiques (serveurs, power users, ...) , les personnes sont censé savoir ce qu'elles font, donc si elles veulent mettre une limite ou pas ;)) >
[^] # Re: public
Posté par Thomas Douillard . Évalué à 2.
C'est moi ou dans un contexte desktop pur il y a rarement un admin ? etr puis là on parle de la limitation du nombre de processus, pas de la consommation de mémoire, principalement.
Limiter le fork je vois pas qui ça peut emmerder dans le commun des mortels au sens large, sauf à des ultra-spécialistes du parralélisme qui se fichent complètement de la config par défaut ou à des mecs qui sont capables de virer la limite si ils en ont envie et qui veulent tester les limites de leur machine.
[^] # Re: public
Posté par IsNotGood . Évalué à 2.
Si tu ne limites pas de façon significative, par exemple si tu autorises 1000 processus ou même "seulement" 250, c'est largement assez pour rendre la bécane inutilisable (tu lances 1000 processus qui bouffent du cpu, c'est à la porté du commun des informaticiens).
Si ça ne gêne pas, ou du moins si ce n'est pas potentiellement génant, c'est sans intérêt.
> Limiter le fork je vois pas qui ça peut emmerder
Ici (fc6), par défaut c'est "limité" (notes bien les guillements) à 8191 ! Autant dire qu'il n'y a pas de limite et on a le "problème" décrit ci-dessus.
Si c'est un processus malintentionné et qu'il peut faire seulement un fork (inutile d'avoir 8191 ou "seulement" 250 de disponible), il a largement de quoi faire des dégâts (par exemple il peut faire un exec("rm -r -f /")).
[^] # Re: public
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: public
Posté par fork_bomb . Évalué à 3.
[^] # Ha c'est malin !
Posté par Jeanuel (site web personnel) . Évalué à 10.
Y'a toujours un ballot qui veux tester. Merci beaucoup, ça faisait quelques temps que j'avais pas rebouté ma machine.
Non mais quel flan, puisqu'on te dit "PAS TOUCHER", faut PAS TOUCHER... !
[^] # Re: public
Posté par gnumdk (site web personnel) . Évalué à 5.
Le compte par défaut est toujours administrateur...
Microsoft n'a toujours pas compris... Si ils ne violentent pas un peu leurs utilisateurs, ils ne vont pas changer les sentiments sur windows: Garage à virus, spyware, ...
[^] # Re: public
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: public
Posté par CrEv (site web personnel) . Évalué à 3.
"pour installer linux ubuntusaymiekewindobe on m'a dit de télécharger une image de cd mais j'ai juste un fichier compressé, je comprend pas comment on grave"
traduction (de la fin, le début je le laisse ;-) ) -> j'ai les extensions cachées par défaut et mon iso s'ouvre avec mon winrar cracké sans que je soit capable de vérifier le nom complet du fichier que je viens de télécharger, ni de voir les propriétés ou type du fichier
[^] # Re: public
Posté par Anonyme . Évalué à 6.
Au moins, une session trafiquée ça se récupère en deux coup de cuillère a pot.
[1] véridique - mais sur une seule machine -, je sais pas si je dois en être fier. Dans l'absolu, non, ca emmerde le monde pour pas grand chose, mais bon c'est la fnac quand même ...
[^] # Re: public
Posté par Calim' Héros (site web personnel) . Évalué à 4.
[^] # Re: public
Posté par ploum (site web personnel, Mastodon) . Évalué à 9.
Juste pour voir la tête des clients en voyant l'ordi booter avec le logo win98 à l'envers !
(oui, j'avais 17ans en 98)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: public
Posté par Charles-Victor DUCOLLET . Évalué à 2.
[^] # Re: public
Posté par Wawet76 (site web personnel) . Évalué à 10.
On a arrêté de passer nos mercredi et samedi au super-marché quand le fameux 464 est arrivé à la maison, et maintenant on bosse tous les deux dans l'informatique. Halala on rigolait bien à l'époque. C'est plus comme ça maintenant. Déjà, y'a plus de jeunesse mon bon monsieur.
[^] # Re: public
Posté par Édouard Geuten (site web personnel) . Évalué à 2.
# Français
Posté par maggic . Évalué à 2.
Je suis allé faire un tour
[^] # Re: Français
Posté par moramarth . Évalué à 2.
[^] # Re: Français
Posté par frayd . Évalué à 6.
Extraits:
"Le verbe être peut remplacer le verbe aller, dans la langue courante aux temps composés; dans l'usage littéraire au passé simple et au subjonctif imparfait"
(...)
"Ces emplois ont fait l'objet de discussions ."
Troll grammairien pas mort, voir Google...
Puis suit un paquet d'exemples, dont celui-ci:
"Une phrase comme la suivante montre bien la synonymie des deux formules: Moi aussi je suis allé là où vous avez été. (Alain Fournier, Gr. Meaulnes) - La seule différence est que avoir été prédomine dans l'usage familier et être allé dans l'usage soigné."
Voilà voilà, il y a des familiers et des soignés sur linuxfr.
[^] # Re: Français
Posté par Etre-ange . Évalué à 7.
on appelle ça les moules et les daicideurs je crois
# De la confiance relative dans son produit
Posté par moramarth . Évalué à 1.
Le titre devrait plutôt être De la confiance relative envers ses clients.
Peut-être qu'ils veulent cacher des bogues, alors ils se contentent de l'écran de connexion, c'est possible aussi. Mais comme tu parles de surveillance, dans ton journal, je pense que tu faisais clairement référence à la relève actuelle de √λιi, Ploum, Thomas Walraet, Edouard Geuten et tant d'autres…
[^] # Re: De la confiance relative dans son produit
Posté par qdm . Évalué à 2.
[^] # Re: De la confiance relative dans son produit
Posté par dinomasque . Évalué à 2.
Est-ce à dire que les clients qui se risquent jusqu'au rayon Apple tout là bas au fond du magasin sont plus dignes de confiance ou bien que le système des machines l'est ?
BeOS le faisait il y a 20 ans !
[^] # Re: De la confiance relative dans son produit
Posté par moramarth . Évalué à 2.
Que ce soit parce que les macs sont plus robustes ou parce qu'ils inspirent une sainte révérence devant l'objet sacré (plutôt ça à mon avis, au contraire des Windows qui tapent sur le système nerveux), c'est clairement à l'avantage des macs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.