Soucis avec certains produits OpenSource (Nouveau, IcedTea) - Page 4

Au fait, le titre du topic est mal choisi…

Bah non, c'est vous qui avez dévié
(Et je n'ai pas de problèmes de JVM sous Windows, donc il est très bien choisi)

de toute façon ce qui est libre est open source alors ça marche aussi

J'ai jamais eu de souci de dépendances... J'en ai toujours eu les avantages (maj de tous les softs sans aucun souci, collecte des libs transparente etc...)

Depuis que je suis passé à Arch, je n'ai plus de soucis \o/ (sauf un petit -F à mettre quand je passe de nouveau à nvidia, justement, parce que je dois supprimer xf86-nouveau mais pas l'ensemble des dépendances).

Folco (./94) :
J'ai jamais eu de souci de dépendances... J'en ai toujours eu les avantages (maj de tous les softs sans aucun souci, collecte des libs transparente etc...)

Parce que tu es admin, que tu as une connexion internet, et que tu peux mettre tout le système à jour...

Nil (./92) :
Bah non, c'est vous qui avez dévié

Ce n'est pas ça le problème, mais le terme "OpenSource" dans le titre à la place de "libre".

mon dieu il faut absolument modifier ce titre horriblement faux

flanker (./96) :
Parce que tu es admin, que tu as une connexion internet, et que tu peux mettre tout le système à jour...

Tu ne dois pas forcément être admin sur une distribution moderne, il suffit d'avoir les permissions PolicyKit org.freedesktop.packagekit.package-install et org.freedesktop.packagekit.system-update (cette dernière étant activée par défaut pour les utilisateurs locaux sous Fedora; on avait même activé aussi la première par défaut à un moment, mais ça a vite été changé pour des raisons de sécurité).

bref, il faut toujours des droits supérieurs à la normale pour installer des paquets

(Tout comme sous Windows, hein )

(C'est ce qu'on pourrait attendre de n'importe quel système, non, en fait ? De ne pas permettre à n'importe qui d'installer n'importe quoi... )

on pourrait autoriser à installer dans son $HOME, je ne vois pas ce qu'il y aurait de choquant à cela

Oui, voilà. Il n'y a pas de raison d'interdire à un utilisateur d'installer des logiciels qui ont les mêmes droits que lui (sinon, ça veut dire qu'il y a une faille : si un logiciel peut faire quelque chose de malveillant, l'utilisateur peut le faire manuellement aussi). Certains admins systèmes veulent que seuls des logiciels "approuvés" soit utilisés, mais c'est assez utopique, il y a des cas où c'est très casse-pieds (rien que pour ceux font du développement, déjà).

C'est bien sûr totalement différent si on parle de paquets qui ont des droits plus élevés, dans ce cas c'est logique qu'un utilisateur ne puisse pas les installer lui-même.

D'ailleurs, en pratique on peut tout à fait installer soi-même, suffit de tout recompiler dans son $HOME et de se palucher les dépendances à la main.

En pratique, c'est souvent la solution la plus simple...

Zerosquare (./104) :
Il n'y a pas de raison d'interdire à un utilisateur d'installer des logiciels qui ont les mêmes droits que lui

et avec ça, tu te retrouve avec des machines blindées de pourritures qui affichent de la pub, envoient du spam, servent de relai à des attaques...
Après tout, afficher de la pub, n'importe quel utilisateur peut le faire ; envoyer des mails aussi ; et poser un dictionnaire sur F5 aussi ; mais quand c'est un logiciel qui le fait, avec les mêmes droits que l'utilisateur, donc, les conséquences ne sont pas forcément tout à fait les mêmes.

Plus sérieusement, considérant le peu de connaissances qu'a le grand public de l'outil informatique, restreindre un minimum ce qu'ils peuvent faire avec n'est pas une si mauvaise idée...
Même pour du non grand-public, travailler avec un compte aux droits restreints semble normal ; quitte à monter en droits lorsque l'utilisateur en a besoin (finalement, c'est ce que je fais sur mes machines : je suis utilisateur "normal", mais quand j'en ai besoin, j'ai le droit de passer root ; mais au moins quand, en conditions normales, je fais un truc que j'aurais pas du faire, bah ça casse pas le système, et ça n'impacte que moi)

flanker (./103) :
on pourrait autoriser à installer dans son $HOME, je ne vois pas ce qu'il y aurait de choquant à cela

Sous Windows, quand t'as pas le droit d'installer, tu ne peux pas installer dans ton userdir non plus, hein

[cite] squale92 (./106) :

Zerosquare (./104) :
Il n'y a pas de raison d'interdire à un utilisateur d'installer des logiciels qui ont les mêmes droits que lui

et avec ça, tu te retrouve avec des machines blindées de pourritures qui affichent de la pub, envoient du spam, servent de relai à des attaques...
Après tout, afficher de la pub, n'importe quel utilisateur peut le faire ; envoyer des mails aussi ; et poser un dictionnaire sur F5 aussi ; mais quand c'est un logiciel qui le fait, avec les mêmes droits que l'utilisateur, donc, les conséquences ne sont pas forcément tout à fait les mêmes.

Plus sérieusement, considérant le peu de connaissances qu'a le grand public de l'outil informatique, restreindre un minimum ce qu'ils peuvent faire avec n'est pas une si mauvaise idée...[cite]
Sauf qu'actuellement, tu ne peux pas autoriser à installer dans son HOME uniquement. Ce n'est pas parce qu'on en aurait la possibilité que ce serait activé par défaut (et ça n'empêche pas non plus de mettre une confirmation genre sudo )

Même pour du non grand-public, travailler avec un compte aux droits restreints semble normal ; quitte à monter en droits lorsque l'utilisateur en a besoin (finalement, c'est ce que je fais sur mes machines : je suis utilisateur "normal", mais quand j'en ai besoin, j'ai le droit de passer root ; mais au moins quand, en conditions normales, je fais un truc que j'aurais pas du faire, bah ça casse pas le système, et ça n'impacte que moi)

Bien sûr que c'est normal... Sauf que sur Linux c'est un peu binaire, soit tu ne peux rien installer facilement, soit tu peux tout installer. Ça serait cool de pouvoir installer facilement dans son HOME (surtout que ça ne changerait rien à la sécurité vu qu'on peut déjà le faire)

bah après, libre d'installer ce que tu veux dans ton home ; par contre, si tu veux faire autrement que ce qui est prévu (i.e. installer au niveau système), il ne semble pas surprenant que tu aies à te débrouiller (i.e. à ne pas utiliser le système de paquets de ta distrib).

Une solution qui permettrait d'installer des paquetages normaux dans son $HOME passerait obligatoirement par chroot (ou quelque chose qui ressemble, comme systemd-nspawn). Le problème, c'est qu'actuellement, les outils disponibles peuvent être contournés (attaques "échappement du conteneur") et donc il est fortement déconseillé de donner accès à ces outils à des utilisateurs non-admin. Mais en principe ce n'est pas impossible de permettre à un utilisateur normal de créer son chroot dans son $HOME et d'y installer ce qu'il veut. Ce n'est pas possible sans chroot parce que les noms des dossiers système doivent être respectés.

(Sinon, comme déjà dit plusieurs fois, une solution existe déjà, c'est la virtualisation. Mais une VM complète est une solution plus lourde que nécessaire, un chroot devrait normalement suffire.)

Kevin Kofler (./110) :
(Sinon, comme déjà dit plusieurs fois, une solution existe déjà, c'est la virtualisation.

Sauf que ça implique que l'administrateur accepte qu'un utilisateur normal puisse gérer une machine virtuelle, ce qui est très dangereux : une machine hors de contrôle, pas forcément protégée, pas forcément à jour, sur le réseau, c'est pas fraaanchement l'idéal.

Pourtant c'est le plus sûr, rien dans la machine virtuelle ne peut s'échapper en dehors de la machine virtuelle, et en principe ça ne permet pas plus sur la machine hôte qu'un simple compte utilisateur ne permet.

oui mais tout de la vm peut s'échapper sur internet. Et pourquoi pas, revenir sur la machine hôte tel un boomerang des temps modernes.

Là aussi, ça ne change rien par rapport à un compte utilisateur. Une VM ne permet rien qu'un compte shell ne permet pas. La preuve: Tu peux faire tourner un émulateur purement logiciel en tant que simple utilisateur!

Cross : Exactement. Ta VM peut très bien devenir un zombie, être pourrie de virus qui se diffusent sur le réseau interne, et tutti quanti. Donner à un utilisateur les droits d'administrateur d'une VM, ça revient ni plus ni moins à donner la clé pour pourrir le réseau.

Au risque de me répétér ():

Kevin Kofler (./114) :
Là aussi, ça ne change rien par rapport à un compte utilisateur. Une VM ne permet rien qu'un compte shell ne permet pas. La preuve: Tu peux faire tourner un émulateur purement logiciel en tant que simple utilisateur!

Pas d'accord. Typiquement : tu as un système protégé et à jour sur lequel tu installes une VM avec un système à la charge de l'utilisateur. Ce système hébergé n'est pas à jour et a une faille qui lui permet (au hasard, tiens) de prendre contrôle de la machine suite à un bug dans le service FTP. La machine virtuelle se fait hacker, et le hacker y installer un spambot qui inonde internet avec du courrier indésirable. Heureusement, l'admin réseau est malin : le port 25 est coupé par défaut (ouf). Par contre, le hacker y installe un keylogger et plusieurs autres outils et récupère un certain nombre d'informations précieuses (mots de passe, contenus du presse-papier partagé par la VM et l'hôte, etc.).
Donc non, ça n'a rien à voir

L'utilisateur pourrait faire tourner une telle VM hackable en émulation logicielle avec juste la permission d'exécuter dans son $HOME.

Tu connais beaucoup de systèmes de virtualisation qui ne nécessitent rien au niveau noyau ? (Il y en a probablement, hein, mais tellement compliqués à mettre en oeuvre que ça compte pour peanuts...)

qemu-system* peut être executé en non-root.