> 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.
[^] # Re: Si j'ai bien tout compris...
Posté par 007 . En réponse à la dépêche La prise de contrôle à distance avec NX. Évalué à -1.
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.