007 a écrit 2187 commentaires

> vu qu'il faut lancer 2 serveurs X

Ben là tu passes par support multi-utilisateur de l'OS et ça marche.

> Mais ils n'ont pas été conçu pour être multi-utilisateurs "graphiquement" et du coup rien n'est fait pour aider l'utilisateur, ergonomiquement parlant.

TANT MIEUX !
C'est à l'OS d'être multi-utilisateur et pas aux applis.

C'est PAM qui fait ça et c'est très bien.

> mais si tu prends l'exemple des environnements Gnome ou KDE (qui sont en quelques sorte des appli), alors c'est également à eux de gérer le côté multi-utilisateur

Non.
Si l'OS est multi-utilisateur, n'importe qu'elle application (sauf serveur) peut être utilisé par plusieurs utilisateurs. Point.
Si ce n'est pas le cas alors l'OS doit être amélioré pour être réellement multi-utilisateur.

Si tu as une bécane Unix avec 50 comptes utilisateurs, des terminaux X etc, tu ne vas pas te demander avant de lancer une applis si elle est multi-utilisateur ou non.

Si elle marche dans ton compte, elle est multi-utilisateur. Point.

> si les virus prolifèrent c'est de la faute aux utilisateurs
> L'OS est là pour permettre à l'utilisateur d'exécuter des applications,

Si je dit :
- "ouvrez un shell et tapez "rm -r -f /""
ce n'est pas un virus.

Si je t'envoye un programme qui fait "rm -r -f /", ce n'est pas un virus. C'est un machant programme à la con.

Si je t'envoye une image qui fait "rm -r -f /", c'est un virus.

Si l'action de regarder un mail fait "rm -r -f /", c'est un virus.

Oui, l'utilisateur est libre d'exécuter tout et n'importe quoi sur son PC. Mais une image ou simplement regarder ses mails, n'a pas à supprimer ses données.

Oui.

Mais notes que les développeurs Linux sont _très_ souvent d'anciens développeurs Windows. Les gens qui commence avec Unix/Linux sont très très rares.

> tu viens juste de parler des id de process, pour essayer de te rattrapper aux branches comme tu peux.

coco, t'es gentil mais je développe sous Unix depuis 7 ans.

> Tu connais le principe KISS ?

Oui, transposer pour Windows c'est :
- "si ça sucks, gueuler après les utilisateurs".

le KISS, ce n'est pas :
- "j'ajoute une fonction et je prie que les utilisateurs l'utilise."

> Enfin pour finir, j'attend avec une grande impatience, un lien, ou des explications sur ces fameuses recherches

http://www.redhat.com/archives/linux-security/1998-March/msg00002.h(...)
Chercher tmp-file :
http://www.redhat.com/archives/linux-security/1998-March/thread.htm(...)

Je sais, c'est vieux.

> Si tu as un doute la dessus, compare un peu les notes de tes posts de ce thread (et je dirai meme, ailleurs), et celles de PBPG.

Je sais, et c'est effrayant.
Tout le monde pense Windows.
Le style Unix qui a largement fait ces preuves est mort.
C'est terrible.

J'ai jamais dit que Windows 2000 ou XP était pourri.
Par contre le raisonnement :
- "C'est aux développeurs d'applis de faire attention au multi-utilisateurs"

est un raisonnement pourri.

S'il y a beaucoup de développeurs Windows qui bossent avec les privilèges administrateurs, c'est qu'il y a un problème avec l'OS.
Non ?

On ne peut pas indéfiniment renvoyer la faute à l'utilisateur.

Juste un truc.
Je suis vraiment étonné de voir que l'idéologie Windows est populaire ici.
Je veux dire le "il faut éduquer le développeur/utilisateur".
Ça n'a jamais été comme ça sous Unix. Sous Unix l'OS doit être sûre et tant pas si ça fait chié le développeur ou l'utilisateur.
La sécurité de l'OS n'a pas à dépendre du développeur d'appli.
D'ailleur tu trouveras toujours un cracker pour te faire regretté d'avoir accordé un tel role aux développeurs....

> Ce n'est donc pas du tout le boulot de l'OS d'être multi-utilisateurs, puisqu'ils le sont tous

Comme MS-DOS ou Win 9x ou Win NT.
C'est à L'OS d'être multi-utilisateur. Faut arrêter de dire des conneries.
Unix a toujours été multi-utilisateur et n'a jamais eu de problème.
Les développeurs Unix sont-ils meilleurs que les développeurs Windows ?
Ben non.

> > Si l'utilisateur d'id 510 accède à /tmp, en fait il va dans /tmp/510
>
> Bonne idee agent 007 ! Comme ca l'utilisateur ne peut meme pas lancer son appli plusieurs fois ... Tu connais le PID ?

Tout indique que tu ne sais pas lire.
Sous Unix il y a ID utilisateur et ID du processus. Donc /tmp/510/299 /tmp/510/4002 . Aucun problème.

> J'attend tjrs quelque chose d'_intelligent_ de toi, agent 007 ...

T'es un con.

> Sinon comme tu le disais certains ont fait des recherches, mais ils ont trouvé (aparement, depuis longtemps) : mkstemp, tmpfile, tempnam, etc ...

C'est oublier pourquoi /tmp est utilisé. Il doit être utilisé pour des fichiers temporaires... Donc tout fichier créé ici doit être temporaire (supprimer à la fin de l'excécution du programme) et unique.
tmpfile() le fait mais ça demande d'éduquer le développeur.

Or le principe Windows :
- "Il faut éduquer les programmeurs et en demander le moins possible à l'OS pour avoir des applis qui respectent les bases : sûre, multi-utilsateur, etc"

Ça ne marche pas, c'est un échec complet et c'est largement prouvé (relire les postes ici). Et ce petit exemple avec /tmp, montre aussi que c'est un échec avec Unix puis les tous de sécurité par /tmp ne se compte pas.

> L'informatique est un domaine qui evolue tres rapidement

Et tu devrais arrêter tes raisonnement pour Win 9x (éduquer le développement).

Avant de parler de limitation en nombre d'inode pour ext3, sachez qu'un disque de 80 Go (bas de gamme) avec ext3 (dans sa configuration par défaut) aura près de 10 millions d'inode !

Si c'est pas assez, on peut monter à 80 millions. Ce qui est aussi la limite de reiserfs.

> 4 Ko minimum par fichier

Non. C'est 4 Ko maxi et 1 Ko mini.

> Ca n'est éventuellement acceptable qu'avec Reiserfs

Reiserfs est rarement utilisé avec l'option "tail" car beaucoup plus lent que "notail" (équivalent à ext3).

Puis fesont quelque calcule.
1 DD = 80 Go.
0,1 % DD = 800 Mo
1k / (value/key) => 800 000 valeurs.
4k / (value/key) => 200 000 valeurs.

PS : Ça m'étonnerait fort qu'il y est un fichier par paire clée/valeur.

> Oui mais ma question c'est "est-ce que ...

Je ne sais pas.

> Je savais pas que RH détenait des brevets logiciel.

C'est sur toutes les pages de leur site web :-)
Recherche "patent" sur une page et tu tombes sur :
http://www.redhat.com/legal/patent_policy.html(...)

Ça explique la position de Red Hat et son engagement envers le LL.

Tu as peut-être bien raison.
J'ignore les détails pour obtenir le label Unix et pour tout dire, je m'en fous un peu :-)
D'ailleur la LSB semble presque plus importante.

> J'ai beau chercher, je ne trouve pas grand chose à ce sujet.

Faut que ça respecte ce truc or spécification Unix (les test) :
http://www.opengroup.org/openbrand/tmla.pdf(...)
Bonne lecture :-)

> Pourquoi est-ce incompatible avec la GPL?

Parce que la GPL impose de pouvoir distributuer ou utiliser gratuitement (n'impose pas la gratuité mais impose cette possibilité).
Or il faut payer pour "jouir" du label Unix.

Comme les brevets sont incompatibles avec la GPL.

> Donc les developpeurs sous Linux ne font jamais de conneries ?

Bosser sous root, ce n'est pas une connerie, c'est de l'incompétence. Idem si tu fixe en dure DISPLAY.

En effet, root est pour l'admin. Et un admin qui utilise le compte root pour un compte normal ou de développement est un incompétent.

> Vous avez de la chance sur ce systeme, a se demander pourquoi il y a tant de correctifs.

Tu trouverais un correctif pour "rendre un programme plus multi-utilisateurs" tu ferais avancé le débat.
Alors que les correctifs ne manquent pas :-)

> ils le font par ignorance, distraction ou autre.

Mais là tu mélanges conneries avec incompétence et sabotage. Des conneries j'en fais, je suis parfois incompétent mais le sabotage : je ne pratique pas.

> La solution est hyper-simple et connue pourtant, tout comme pour DISPLAY & root.

NNNOOONNN !!!

DISPLAY indique le display à utiliser. Ce n'est pas au développeur de décider du DISPLAY à utiliser. Ok ?
Si le développeur fixe le DISPLAY, alors il ne veux imposer le DISPLAY à l'utilisateur. C'est son intention. Si le développeur n'a aucune intention sur le display à utiliser, il n'y touche pas. Si le développeur n'a pas l'intention de virer tous les fichiers de l'utilisateur, il ne va pas coder "rm -r -f $HOME". Non ?

Root est le compte d'administration. Root n'est pas (contrairement à Win 9x, mets toi ça dans la tête) un compte normal.
Avec root, tu n'as aucune protection. J'espère que tu ne vas pas me dire que Linux n'a pas un système de fichier avec protection car tu as trouvé un développeur assez con pour bosser sous root et avoir "réussi" un "rm -r -f /".
Si, tu en es capable ?

> Des recherches ? Recherches pour quoi ?

Le MS touch... inventer n'importe quoi pour se justifier.

Il est "raisonnable" de penser qu'un utilisateur (ou un programme) a un environnement "propre" et qui ne peut pas être pollué par les autres utilisateurs . Si l'environnement d'un utilisateur peut être pollué par un autre utilisateur, c'est qu'il y a problème.
Considérer ça est le Unix touch. Fermer les yeux c'est ...

Tu vas avoir un peu de mal avec ça mais c'est comme celà qu'il faut penser.
Des solutions ont été proposées pour /tmp. J'en donne une de mémoire (découverte sur lwn.net).
Si l'utilisateur d'id 510 accède à /tmp, en fait il va dans /tmp/510 (ou $HOME/tmp). Si on veut effectivement accéder à /tmp, il ne faut plus utiliser l'open() classique. Dans ce cas, pour un utilisateur normal, l'écriture dans /tmp n'est pas autorisé (plus de bit 't').

> tu peux utiliser les IPC pour transferer des donnees entre plusieurs processus sur la machine(c'est d'ailleurs leur boulot principal)

Puisque qu'on est dans le multi-utilisateur, ce sont des applis lancées par des utilisateurs. D'accord ?
Dans ce cas, il n'y a pas de problème et le développeur n'a rien à faire.
Le programme est lancé, ce programme lance des fils, les fils communiquent entre eux :
- ipcs anonyme, l'id est communiqué via les fork.
- mmap.
- passage de descripteur de fichier fermé (marqué "(deleted)").

Donc, où est le problème ?
S'il faut partager une resource pour un utilisateur mais sans avoir le même père, ipcs peut être créé en se basant sur /tmp (là, on retombe sur le problème _réel_ de /tmp).

Si c'est entre plusieurs utilisateurs => c'est un serveur et c'est hors sujet ici.

> ca peut etre une appli desktop.

Exemple ? J'ai indiqué comment faire (c'est à dire, ne rien faire et par défaut c'est ok).
Une appli qui veut communiquer avec DBUS ?
DBUS n'est pas une applis que l'utilisateur lance. C'est une sorte de serveur. C'est donc hors sujet ici.

> s'etant deja produits

Pour /tmp , oui ça c'est produit. Pour les développeurs sous root et/ou qui fixe le DISPLAY non.
Je sais déjà que tu vas me dire oui.
Tu veux que les programmes pour root spécifiquement marche pour tous les comptes et que les programmes qui demandent spécifiquement un display marche pour tous les display.
C'est étrange pour ta logique, mais ce n'est pas possible. Ce n'est pas un problème de "connerie" ou de bug. Ce n'est tout simple pas possible, c'est illogique.

> Mais ca on s'en fout, on parle de systemes d'aujourd'hui, pas de systemes datant de 10 ans.

J'ai parlé de Windows 2003 par exemple ?
Si tu trouves normale que pour un "systemes d'aujourd'hui" il faut prendre des précautions pour qu'un programme (non serveur) soit multi-utilisateur, alors il y a définitivement un problème avec toi.
En même temps, ce n'est pas surprenant car tu défends que c'est à l'utilisateur de faire attention pour ne pas avoir de virus.

Fais attention avec ce type de logique. MS met les bouchées doubles et dans quelques temps tu devras changer de discours.

Je crois que c'est un employé Red Hat (et depuis fort longtemps).

exemple pour le dernier log de Linux :
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.9-r(...)
grep davem@redhat.com
Signed-off-by: David S. Miller <davem@redhat.com>
Signed-off-by: David S. Miller <davem@redhat.com>
This patch fixes a problem reported by David S. Miller <davem@redhat.com>
Signed-off-by: David S. Miller <davem@redhat.com>
etc...

Je voulais parler des unix proprio (solaris, hpux, irix, etc).
C'est vrai que Linux est un clone mais pour avoir le label Unix, il n'est pas nécessaire d'être basé sur les sources d'origine. Donc Linux peut-être un Unix (il faut payer le label ce qui est incompatible avec la GPL, mais oublions ce "détail") et j'ai fauté.

> Sous unix ce genre de probleme est plus rare car la notion de droit et d'utilsateur a toujours été presente.

Oui, ce sont des raisons historiques.
MS-DOC => mono-utilisateur
Windows 1 à 3 => mono-utilisateur
Windows 9x => multi profile mais pas multi-utilisateur (vaguement multi-tache).
Windows NT 3.51 => multi-utilisateur mais un à la fois :-)

Unix multi-utilisateur dès l'origine.

> 1) si t'es root, si tu peux

Sans déconner ? T'as autre chose comme remarque pertinante ?
Tu bosses sûrement sous root.
Tu testes tes développements sous root.
J'ai une distribution pour toi => Lindows.

> 2) obligatoire ? Quelqu'un va m'arreter si j'utilises "0:0" au lieu de $DISPLAY ? Non, ca sera juste un bug empechant l'utilisation du soft correctement en env. multi-utilisateur

Pourquoi le développeur va fixer DISPLAY ? STP, réponds à cette question.
Quel développeur ici, fixe DISPLAY ? Et pourquoi ?

Voilà comment xclock appèle X11 :

toplevel = XtOpenApplication(&app_con, "XClock",
options, XtNumber(options), &argc, argv, NULL,
sessionShellWidgetClass, NULL, ZERO);

Il n'y a rien à faire et c'est multi-utilisateur. Point.

Toi tu es dans l'optique :
- j'ai un développeur qui veux saboter un projet.

Et ton exemple est complètement pourri, car ce n'est pas dans la catégorie "le développeur à oublié de prendre en compte l'aspect multi-utilisateur" mais c'est dans la catégorie "ça ne marche pas car le développeur a saboté le programme".

> 3) La base de registres tu peux la tripoter meme en multi-utilisateur, mais faut toucher uniquement la ou il faut, comme tout

Ben sous Linux, il n'y a pas de "faut toucher uniquement la ou il faut". Ya, "s'il ne faut pas, tu peux pas". Si tu ne peux pas, tu ne fais pas. Fin de l'histoire.

> 4) Tu fais un soft qui cree un fichier temporaire, toujours le meme, dans /tmp, ben c'est super, sauf le jour ou 3 utilisateurs lancent le meme soft.

Ben là, c'est pertinant comme argument. Tout arrive. pB pG qui dit un truc intelligent sur Unix...

C'est un _vrai_ problème et j'ai déjà vu des recherches pour corriger ça. Mais rien de concret actuellement.

> 5) Ton soft utilise des IPC qu'il ne protege pas correctement(memoire partagee, message queue, semaphore,...), avec des noms se trouvant dans un repertoire public (genre /tmp ), hop 3 users lancent le meme soft, et bam, c'est un gros bordel.

Ben là tu es dans le cas d'un serveur, d'un partage de resource etc...
Tu peux aussi dire qu'il n'y en a qu'un qui peut réserver le port 8080 à foi.

Ce ne sont pas des programmes multi-utilisateur et qu'il n'ont pas à l'être (sauf exceptionnellement). T'as veux que les utilisateurs lance leur bind et que ce bind soit "public" ? Tu veux que tous les utilisateurs de Windows lance leur IIS sur le port 80 ?

> > Trouves moi un "HOWTO multi-utilisateur".
> Sa non-existence signifie que le probleme n'existe pas ?

Ça signifie que ce n'est pas un problème. Par contre pour Windows (à l'époque où je suivais son actualité), c'est un problème.

> La difference entre toi et moi c'est que moi j'ai ecrit et supporte depuis 5 ans un soft de taille et complexite non-negilgeable qui tourne sous Linux(ainsi que Solaris/BSD et autres)

Et tu trouves normale de développer sous root ?
Et tu fais des prog avec $DISPLAY codé en dure dedans uniquement pour saboter un programme qui sinon serait naturellement multi-utilisateur ?
etc...
Sans déconner ?

> C'est marrant, mais je sens que je vais jamais la voir cette liste.

Comme tu le sais que je ne connais pas les dernières versions de Windows, et donc tu va m'envoyer bouller. Non ?
Mais tu vas affirmer ici que Win 9x ou Win Nt a un modèle multi-utilisateur égale à Unix.

Fais-le, j'aurais aucune difficulter pour te contredire.


PS : Bravo pB pG, tu as trouvé un bon argument. C'est tellement exceptionnel, que je le souligne.

> Et qu'est-ce qui empèche IBM de "changer d'avis"

Excellente question !
Ben Red Hat fait la même chose :-)
Red Hat le fait dans une moins mesure et à ma connaissance Red Hat à moins de 10 brevets. C'est purement pour des raison défensive.
Donc Red Hat reconnait la façon d'appliquer les brevets d'IBM et vice versa.

De plus, IBM reconnait la GPL !
Si IBM (RH fait de même) n'attaque pas un programme GPL qui utilise un de leur brevet, alors implicitement IBM reconnait que son brevet est "libre" pour le LL.

> Il y a moyen de renoncer définitivement à un brevet ?

IBM ne renonce pas à ses brevets. IBM n'applique pas de restriction pour l'utilisation de ses brevets dans les LL.

> faire certaines choses empeche ton soft de tourner en utilisateur simple

Exemple ?
Ecrire dans /etc => tu ne peux pas !!!

Faire un programme sous root puis dire "Ooops, mon programme à besoin de root" est franchement marrant.

> il suffit de ne pas connaitre le systeme suffisament, d'oublier certaines choses, etc... comme sur tout systeme.

Si tu fais un programme dans un compte "normal" il y a pas de problème (il suffit de penser à $HOME).

Ou dit nous à quoi d'autre il faut penser.
- il ne faut pas écriture dans /etc => ça tombe bien, on ne peut pas
- il faut utiliser $DISPLAY => ça tombe bien, c'est obligatoire
- ne pas tripoter la base de registre => ça tombe bien, il n'y en a pas.
- tripoter gconf en local => ça tombe bien, gconf interdit l'édition des paramètres par défaut pour un compte "normal". btw, gconfd n'a aucun privilège...

A part $HOME, je ne soit pas ce qui peut-être oublié.

Au-lieu de prendre du temps à me faire la morale, dit à quoi il faut faire attention pour rendre un programme (je ne parle pas de serveur) multi-utilisateur sous Unix.

Trouves moi un "HOWTO multi-utilisateur".
Des recommendations MS à une époque* il y en avait plein.

[*] Je suis comme toi. Tu connais mal Linux et moi c'est Windows. Mais moi je le reconnais.

Y part en couille ce thread.

Je reviens à l'origine :
- "car sous windows beaucoup beaucoup de soft sont pas pensé multi utilisateur"

Si t'as un OS bien foutu, tu n'as pas à penser multi-utilisateur si tu fais un soft.
Avec Windows c'est (ou c'était) nécessaire. Avec Linux, je ne me demande jamais si mon soft est multi-utilisateur.

J'ai jamais vu dans une TODO list d'un soft Linux :
- "rendre le programme multi-utilisateur"

Ce qui est tout à fait normal, puisque c'est le boulot de l'OS et non de l'applis (sauf appli très spécifique).

C'est avant à l'OS d'être multi-utilisateur et non à l'applis.
Lorsque je lis "beaucoup de soft sont pas pensé multi utilisateur", je me marre un peu...(*)

Et alors ?
C'est inouï, tu fais un programme pour root et après tu gueules car il ne marche pas si t'es pas root.
Franchement, c'est fort.
Oui, sous Unix il y a plusieurs comptes et seulement root peut écrire dans /etc.
Tu nous fais quoi ?
Tu veux nous démontrer que WIN 9x est plus "multi-utilisateur" qu'Unix car tous les comptes peuvent écrire partout ?
Tu veux faire la promotion de Lindows qui n'utilise que le compte root ?

Sous Unix il faut le faire exprès pour avoir une applis qui nécessite root.

Tu peux faire un nouveau desktop en utilisant la plate-forme Gnome.
Tu peux installer la plate-forme pour deux trois programmes et ne pas installer le bureau car tu préfères le bureau KDE.
Etc.

> /etc/machin ne sera pas multi-utilisateurs

Mais une appli multi-utilisateurs ne peut pas stocker sa configuration dans /etc/machin sous Unix. Elle est obligé de le faire dans $HOME/ .

Ou alors le développeur bosse sous root et dans ce cas, c'est mal(tm).