La liste des nouveautés est ici : http://forums.fedora-fr.org/viewtopic.php?pid=386778#386778 ou dans le journal sur la version alpha : http://linuxfr.org//2009/08/26/25834.html .
La liste des miroirs là (attention, il semble qu’ils n’aient pas tous fini de se mettre à jour à cette heure) : http://mirrors.fedoraproject.org/publiclist/Fedora/12/ et l’ensemble des options pour l’obtenir (torrents, etc.) ici : http://fedoraproject.org/fr/get-fedora .
Journal Sortie de la version finale de Fedora 12 « Constantine »
18
nov.
2009
# Amateur de KDE
Posté par kowalsky . Évalué à 6.
De plus, le driver graphique Intel refonctionnant parfaitement, c'est fluide et c'est du bonheur.
[^] # Re: Amateur de KDE
Posté par PegaseYa . Évalué à 3.
[^] # Re: Amateur de KDE
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Amateur de KDE
Posté par Maclag . Évalué à 9.
(Mais pourquoi oh pourquoi poster ce journal un mercredi??)
-----------------------> [ ]
[^] # Re: Amateur de KDE
Posté par Frédéric COIFFIER . Évalué à 1.
Mais je pense que la Fedora 11 a bien évolué en 6 mois (enfin, surtout KDE qui a mûri).
Par contre, j'ai l'upgrade Fedora 12 par preupgrade a complètement foiré rendant le système complètement inutilisable. J'ai du refaire une installation complète de Fedora 12 (Heureusement que le /home était bien sur une partition dédiée ce qui a limité la casse). D'un autre côté, ça confirme une fois de plus mes impressions sur Fedora : une Fedora n'est stable qu'à la moitié de son cycle de vie (soit au bout de 6 mois).
[^] # Re: Amateur de KDE
Posté par fleny68 . Évalué à -9.
Le pluriel s'impose-t-il vraiment?
désolé, j'ai pas pu résister...
[^] # Re: Amateur de KDE
Posté par Yohan_B . Évalué à 2.
De plus, le driver graphique Intel refonctionnant parfaitement, c'est fluide et c'est du bonheur.
C'est beaucoup mieux c'est sûr mais il y a encore des bugs gênants (au moins avec le chipset X4500HD que j'utilise).
Ce bug http://bugs.freedesktop.org/show_bug.cgi?id=24556 par exemple avec firefox (100% usage CPU, sysprof dénonce drm_do_probe_ddc_edid). Il est fermé mais je vais le rouvrir parce qu'il existe encore même s'il est nettement plus dur à reproduire. Mon dernier score actuellement avec ce bug (sur la machine sur laquelle je tape ce commentaire) :
ls -lh /var/log/Xorg.0.log
-rw-r--r-- 1 root root 54M nov. 18 20:37 /var/log/Xorg.0.log
Le fichier fait environ 800000 lignes mais j'ai obtenu jusqu'à 2 millions de lignes.
J'ai aussi un plantage dès que j'essaye de lancer une application 3D (bon OK glxgears fonctionne).
Enfin, avec KDE j'ai un plantage systématique de Xorg en utilisant les effets de bureau. En particulier, avec l'effet de présentation des fenêtres (type exposé sur OSX) lors du alt+tab, le plantage est très rapide (à première vue la backtrace indique drm_intel_gem_bo_start_gtt_access).
Je n'irai donc pas jusqu'à dire que c'est parfait.
[^] # Re: Amateur de KDE
Posté par ZeroHeure . Évalué à 4.
Les devs X font à peu près le même commentaire qu'Eric Anholt un peu partout: "the desktop keeps getting told that things have changed".
Bref, ça vient du noyau, mais pourquoi ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# amateurs de css
Posté par BAud (site web personnel) . Évalué à 2.
http://linuxfr.org/css.html
(zazooo_fedora.css la dernière pour ceux qui chercheraient à f)
et pour ceux motivés par faire une dépêche étoffée, il est encore temps : signalez si vous démarrez en donnant un ETA histoire de prendre en compte vos suggestions pour compléter celle dans le pipe qui est un peu lacunaire ;-) (manque les principales nouveautés notamment)
le wiki http://demoll.tuxfamily.org/linuxfr/NewsLinuxFr reste à votre disposition pour créer une page NewsFedoraConstantine pour du travail collaboratif
[^] # Re: amateurs de css
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 2.
et le journal aussi d'ailleurs
[^] # Re: amateurs de css
Posté par BAud (site web personnel) . Évalué à 2.
la seule news que nous avons est encore moins fournie que http://www.h-online.com/open/news/item/Fedora-12-released-86(...) (au-delà des nouveautés indiqués dans la dépêche en cours).
c'est dire combien fedora n'apporte rien, ni même un changelog ? je pensais qu'il y avait 2-3 ambassadeurs fedora dans le coin (pan !).
c'est bien pour cela que je fais ce commentaire :
- sur linuxfr, nous avons un niveau d'exigence au-delà de la moyenne =
+ qu'un simple changelog, mais que sont les réels changements apportés par la distro (pas un lien hein, *des* liens vers les ML pour montrer les contributions intégrées et disponibles, Fedora étant plus un projet qu'une simple distro, un leader, en français un précurseur pour éprouver des technos que d'autres sont susceptibles d'adopter)
- pour fedora, il y a un traitement spécial : css + attente sur les apports pour les 6 mois à venir de toutes les autres distros (KMS comme Mandriva Linux, quelques attentes sur le pilote nouveau, quelques révélations sur Red Hat... j'en oublie virtualisation inside)
# /.
Posté par GCN (site web personnel) . Évalué à 3.
--> http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-L(...)
Plutôt étrange cette nouvelle fonctionnalité, nan ?
[^] # Re: /.
Posté par Albert_ . Évalué à 2.
[^] # Re: /.
Posté par GCN (site web personnel) . Évalué à 3.
Votez ~Albert_ ;).
[^] # Re: /.
Posté par IsNotGood . Évalué à 9.
Ne permet pas l'installation de tous paquets signés, mais uniquement de paquet dont la signature est validée (par défaut les signatures de Fedora évidemment).
Donc on ne peut pas installer n'importe quoi, on ne peut pas installer le premier rootkit trouvé sur le web.
Ce n'est que pour packagekit qui ne permet pas d'installer un vieux paquet avec une faille de sécurité.
Ce n'est pas autorisé pour yum, rpm, etc.
Ça ne permet que l'installation, pas la suppression (donc on ne peut pas "pourrir" le système).
Sous Fedora (sauf certains paquets par défaut) les services ne sont pas lancé par défaut.
Donc installé un service serveur qui a un trou de sécurité ne permettra pas de l'utiliser.
Cette fonctionnalité ne peut pas être utilisée à distance (ssh ou autre), il faut avoir la console. Si on a un accès physique à la bécane (comme c'est le cas pour avoir la console), c'est facile d'être root (suffit de booter sur un CD, etc) et d'installer n'importe quoi. Ce "problème" d'accès à la bécane est indépendant de l'OS.
Ce changement a été largement discuté il y a plusieurs mois et peut être annulé avec une ligne de commande.
[^] # Re: /.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Je trouve la fonctionnalité bien. Un peu améliorable, mais bien.
Plein d'applis n'ont pas besoin de droits différents de ceux de l'utilisateur, ne sont pas SUID-root, n'ouvrent pas de port < 1024…
Bref, j'ai *longtemps* souhaité une telle fonctionnalité… Pouvoir simplement utiliser le système de packages de la distribution (ou de l'OS) pour installer des logiciels utilisateurs…
Il suffit de tagguer les applis qui n'ont pas besoin de droits particuliers, et hop, les utilisateurs peuvent les installer. ET souvent, même si t'as un /etc/foo.conf, tu peux utiliser ~/.foo.conf aussi… C'est comme une compilation à la main dans son $HOME, sauf que ça profite à tous les utilisateurs qui voudraient ce logiciel (vu que l'install est globale, tout le monde a accès au logiciel), et ça charge moins l'admin système (qui peut faire un script n'autorisant l'installation de logiciels qu'au plus 1 fois par semaine par utilisateur, par exemple, ou filer l'accès au logiciel qu'au groupe des sous-admins locaux, etc)
Ceux qui ont peur de se faire r00ter avec une méthode comme ça devraient arrêter de filer un compte soit root soit guest à tous leurs utilisateurs et (ré)apprendre qu'il y a des droits, sous unix…
[^] # Re: /.
Posté par IsNotGood . Évalué à 7.
Je ne poste plus beaucoup, c'est mon score par défaut...
[^] # Re: /.
Posté par Misc (site web personnel) . Évalué à 3.
Exemple 1 : qu'est ce qui se passe si tu coches tout les paquets kde et gnome et xfce ? En dehors de remplir ton disque ( attaque qui est déja possible dans tout les cas, grace à logger, donc qu'on va éviter de prendre ce facteur en compte ), est ce que ça ne risque pas de pourrir le menu de tout les utilisateurs ?
Exemple 2 : les plugins yum sont activés automatiquement, c'est pas mal, mais est ce que je veut vraiment avoir le plugin presto ou remove-leaf dans mon dos, je suis pas sur. ( en fait, pour presto, je suis sur que non j'ai retiré le dit plugin ). De même, empathy et les plugins telepathys ( notament telepathy-haze et le reste ) peuvent se marcher dessus, il se passe quoi ? Il se passe quoi quand quelqu'un installe un truc avec une alternative systemwide que je veut pas ( exemple, java ou gcc ) ?
Exemple 3 : les serveurs sont pas lancés par défaut au niveau du systeme, mais quid des demons activés via dbus, des programmes lancés pour chaque session ( beagle ), des changements et des conflits sur le mime types, des applis webs installés system wide, etc ?
Exemple 4 : Je peut pas installer de paquets avec une faille de sécurité corrigé, mais quid des paquets avec des failles de sécurité non corrigés ? ( et qu'on me dise pas "fedora corrige toute les failles de secu plus rapidement que tu n'arrives à les trouver" ).
Exemple 5 : Est ce que packagekit est capable de gerer correctement les tags Conflict: et Obsoletes ? ( ie correctement, cad en demandant une authentification ) ? ( j'ai pas réussi
Enfin si pour toi, "il faut avoir l'accés console donc c'est pas grave", pourquoi est ce que fedora n'a pas fait le choix de la cohérence en proposant ça aussi pour yum ?
Pourquoi est ce que le changement d'heure ( qui requiert le mot de passe root en f12 ) est t'il plus bloqué que l'installation des rpms ?
Et au passage, la ligne de commande n'est pas la méthode la plus perenne, c'est de taper un gros bout d'xml dans un fichier ( cf https://bugzilla.redhat.com/show_bug.cgi?id=534047 ).
Perso, je trouve que la fonctionnalité n'est pas si mal, mais ça devrait être reservé au premier utilisateur par défaut. Ie, celui que ubuntu, os x et tant d'autres identifient comme étant "sans doute l'admin". AH oui, et puis ça aurais pu être annoncé dans les releases notes avant de passer sur /. . Soit tout le monde s'en fout chez fedora, soit tout le monde a oublié ( perso, j'ai une fedora 12, et j'utilise tellement peu souvent packagekit que j'ai même pas vu ce comportement ).
[^] # Re: /.
Posté par IsNotGood . Évalué à 0.
Pour un système vraiment multi-utilisateur, c'est un problème.
Mais ses systèmes ont un admin.
les serveurs sont pas lancés par défaut au niveau du systeme, mais quid des demons activés via dbus
Que des services locaux.
Je peut pas installer de paquets avec une faille de sécurité corrigé, mais quid des paquets avec des failles de sécurité non corrigés ?
Si le programme n'est pas utilisé, où est le problème ?
S'il est utilisé, ben il faut faire comme d'hab, attendre la correction du bug.
Est ce que packagekit est capable de gerer correctement les tags Conflict: et Obsoletes ?
Ce n'est pas packagekit qui le gère, mais yum (utilisé par packagekit).
Enfin si pour toi, "il faut avoir l'accés console donc c'est pas grave", pourquoi est ce que fedora n'a pas fait le choix de la cohérence en proposant ça aussi pour yum ?
Yum n'utilise pas policykit donc yum ne peut pas le faire.
Pourquoi est ce que le changement d'heure ( qui requiert le mot de passe root en f12 ) est t'il plus bloqué que l'installation des rpms ?
Un système à l'heure, est à l'heure. Puis il suffit d'installer ntp pour règle ça de façon définitive. Ce n'est cette évolution de packagekit qui va tout régler.
Perso, je trouve que la fonctionnalité n'est pas si mal, mais ça devrait être reservé au premier utilisateur par défaut.
Ou un outil pour indiquer quel utilisateur a accès à cette fonctionnalité. Ça viendra.
[^] # Re: /.
Posté par Misc (site web personnel) . Évalué à 3.
Sinon, ça contourne le fait qu'on ne peut pas retirer de paquets avec pkgkit sans mot de passe.
En fait, en cherchant avec repoquery, j'ai trouvé ce que je voulais, et je vais donc me répondre moi même :
seedit et selinux-policy-targeted sont en conflits. Qu'est ce qui se passe si je fait "pkcon install seedit". Est ce que j'ai un prompt qui me dit "il faut retirer ce paquet ? "
est ce que pkcon rale en me demandant le mot de passe root ?
réponse :
pkcon install seedit ne marche pas. pkcon ne supporte pas et ne gére pas les conflits de paquets, et visiblement ( et contrairement à ce que je crois ), yum non plus.
( perso, j'aurais cru que c'était comme urpmi, un prompt pour dire "il faut retirer ça à cause d'un conflit, oui, non ?" )
# nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 4.
- Niveau securite naturellement c'est foireux mais c'est vrai que jamais aucun serveur n'a ete compromis...
- Niveau administration car les admins qui ne veulent pas que tel ou tel logiciels soit installe vont apprecier la plaisanterie.
Et le pire c'est qu'il n'y a pas de moyen simple pour revenir sur un comportement plus decent semble t'il.
http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-L(...)
Dire que je viens juste de graver un Cd avec fedora 12 dessus... Heureusement c'est du RW sinon cela aurait ete un cd betement utilise. Il n'est pas question que j'installe une distribution qui va permettre a mes neveux et nieces ados d'installer ce qu'ils veulent sans me demander mon avis.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Sak . Évalué à 2.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 3.
Donc si ça se limite "au niveau utilisateur" cela ne me pose pas de soucis. Après, si on peut installer tout et n'importe quoi avec l'équivalent des droits administrateurs, effectivement c'est un peu louche.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par HoloAddict (site web personnel) . Évalué à -1.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par allcolor (site web personnel) . Évalué à 5.
===> []
[^] # Re: nous sommes le 1er avril j'espere...
Posté par ZeroHeure . Évalué à 3.
Attention uniquement les programmes binaires. Un script pourra toujours être lancé ; par exemple avec "perl mon_scripts.pl").
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: nous sommes le 1er avril j'espere...
Posté par gemegik . Évalué à 2.
$ /lib/ld-linux-2.so ~/mon_non_executable
Remarque : pour les exécutables 64bits sous Debian, c'est /lib/ld-linux-x86-64.so.2 qu'il faut utiliser.
En résumé : l'attribut noexec ne protège absolument pas de l'utilisateur.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par IsNotGood . Évalué à 1.
noexec est pour éviter les "boulettes".
[^] # Re: nous sommes le 1er avril j'espere...
Posté par ZeroHeure . Évalué à 3.
Depuis le 2.4.25 et le 2.6 ça n'est plus possible (cherche noexec dans le man de mount) qu'ils disent.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Krunch (site web personnel) . Évalué à 3.
> nieces ados d'installer ce qu'ils veulent sans me demander mon avis
Tu utilises quoi comme distribution ?
$ ./configure --prefix=$HOME/usr
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par gnumdk (site web personnel) . Évalué à 2.
Si la solution de Redhat installe les paquets dans $HOME, à la rigueur, mais si ca attaque directement le système, c'est vraiment pas terrible...
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 5.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 3.
Ensuite je pense que tu sais que tu peux empecher un executable sur la partition home et cela enleve ce genre de probleme.
Dernierement le truc fedora c'est une installation systeme. Cela va installer les logiciels a la racine ce qui est du coup un peu moins pratique a nettoyer.
Pour reprendre ton exemple au dessus un de mes neveux commence a faire ca et je veux faire le menage c'est assez simple:
m -rf /home/neveux
Autre exemple, tu administres des machines sous F12 dans une fac ou ecole d'inge. Naturellement tout le monde sait que les etudiants sont des gens serieux et que ils ne vont pas installer su le systeme tous jeux possible...
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Krunch (site web personnel) . Évalué à 3.
> donc le jour ou ils feront un truc pareil je pourrais leur faire confiance de pas
> me peter tout.
security through obscurity?
> Ensuite je pense que tu sais que tu peux empecher un executable sur la
> partition home et cela enleve ce genre de probleme.
Très bien, il ne te reste plus qu'à sécurisé /tmp, /var/tmp et les 200 autres endroits où ils ont accès en écriture. Puis aussi empécher l'accès à /lib/ld-linux*
$ cp /bin/ls /tmp/ls
$ chmod a-x /tmp/ls
$ /lib/ld-linux-x86-64.so.2 /tmp/ls
Après il y a encore plein d'autres moyens pour faire exécuter du code qui n'est pas sur la machine à la base. C'est pas vraiment le problème.
Le problème c'est plutôt si ça permet d'installer des exécutables suid potentiellement troués ou faire modifier des fichiers de configuration de daemons système.
> Pour reprendre ton exemple au dessus un de mes neveux commence a
> faire ca et je veux faire le menage c'est assez simple:
> rm -rf /home/neveux
$ yum remove `tail /var/log/yum.log`
(ou un truc du genre, j'ai pas de Fedora)
> Autre exemple, tu administres des machines sous F12 dans
> une fac ou ecole d'inge. Naturellement tout le monde sait que les etudiants
> sont des gens serieux et que ils ne vont pas installer su le systeme tous jeux possible...
Et là je vois pas le problème non plus. De mon temps, on installait les jeux dans son $HOME. Si on peut les installer globalement, tant mieux ça fait gagner de la place puisqu'il n'y aura plus 42 copies de Wesnoth sur le système. Après les problèmes de discipline c'est pas avec des moyens techniques que tu vas les régler de toute façon. Enfin, si l'admin est un poil compétent il sait comment désactiver la fonctionnalité.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Misc (site web personnel) . Évalué à 3.
# mount -o noexec,remount /tmp
# cp /bin/ls /tmp/ ; chmod a-x /tmp/ls ; /tmp/ls
bash: /tmp/ls: Permission non accordée
# /lib64/ld-linux-x86-64.so.2 /tmp/ls
/tmp/ls: error while loading shared libraries: /tmp/ls: failed to map segment from shared object: Operation not permitted
# chmod +x /tmp/ls
# /tmp/ls
bash: /tmp/ls: Permission non accordée
# uname -a
Linux test.example.org 2.6.31.5-server-1mnb #1 SMP Fri Oct 23 01:19:00 EDT 2009 x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
Et j'ai pas pris de grsec, tomoyo ou selinux, c'est un kernel de base pas spécialement blindé.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par IsNotGood . Évalué à 2.
Ce qui n'est pas sans causer des soucis.
Ces programmes ne sont pas contrôlés.
Si l'admin n'a pas installé, par exemple, galeon, l'utilisateur peut le compiler à la main s'il le veut. C'est un atout de Linux/Unix. Mais, pas de mise à jour automatique (c'est un gros problème !). Que doit faire SeLinux avec les programmes dans $HOME/usr ? Il ne sait pas car il ne connait pas ces programmes et donc SeLinux autorise tout (il reste les mécanismes de sécurité Unix classiques).
Le firefox (ou galeon) dans /usr/bin est connu de SeLinux. SeLinux sait que firefox n'a pas à lire $HOME/.gnupg/secring.gpg et donc c'est interdit (ce que n'interdit pas les mécanismes de sécurité Unix classiques).
Donc ne pas donner prétexte à installer des programmes dans $HOME est un gain en sécurité.
On peut aussi aller vers un système qui interdit par défaut des exécutables dans $HOME/ (sauf scripts shell car c'est pratique) sans que ça dérange trop les utilisateurs.
Hors serveur, cette fonctionnalité de Fedora n'a pas forcément un impacte négatif sur la sécurité.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par IsNotGood . Évalué à 1.
pklalockdown --lockdown org.freedesktop.packagekit.package-install
OR
Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it
anything you want) and the content should be
[NoUsersInstallAnythingWithoutPassword]
Identity=unix-user:someone;unix-user:someone_else
Action=org.freedesktop.packagekit.*
ResultAny=auth_admin
ResultInactive=auth_admin
ResultActive=auth_admin
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 2.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par IsNotGood . Évalué à -1.
C'est prévu et fait.
que ce comportement a ete assez peu publicite
Quand les gens ne sont pas contents ils l'expriment, s'ils le sont ils ne l'expriment pas.
Faut se méfier de ce type d'impression.
Plus d'une fois Fedora/Red Hat a fait un tolé, mais l'idée est restée.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 3.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 3.
https://bugzilla.redhat.com/show_bug.cgi?id=534047#c105
En particulier ce passage:
It used to be that if you took the time and effort to learn something
thoroughly (as opposed to just copy-n-pasting arcane voodoo from a blog whose
author copy-n-pasted it from some other more obscure source) that your
investment would reap you windfall dividends over the years. This was and is a
HUGE draw and attractiveness to UNIX/Linux.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Littleboy . Évalué à 2.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par IsNotGood . Évalué à 2.
Ils n'installent pas ce qu'ils veulent, mais uniquement les paquets avec une signature approuvée.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par IsNotGood . Évalué à -1.
Il faut le mot de passe root pour valider une signature pour yum (et packagekit). L'utilisateur ne peut pas le faire.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 2.
Mon experience d'administration du pc de mon frere m'a montre que les momes vont pouvoir en installer des trucs inutiles et des jeux qui vont prendre l'ensemble du DD et quel boulot en previsions pour celui qui va administrer cela de passer derriere chaque utilisateur voir ce que celui ci a pu installer et le degager.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par pasBill pasGates . Évalué à 1.
Tu manques de memoire en tout cas, Windows n'a jamais permis a un utilisateur simple d'installer qqe chose sur le systeme en global.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par gnumdk (site web personnel) . Évalué à 2.
Mais Microsoft ne peut revenir en arrière, les gens gueuleraient si tel n'était pas le cas...
[^] # Re: nous sommes le 1er avril j'espere...
Posté par pasBill pasGates . Évalué à 2.
Faire cela signifie que l'on ouvre toutes grandes les portes du systeme a tout un chacun, c'est a mon sens une tres tres grosse betise, car l'admin n'est plus capable de controler ce que le systeme devient, hors la raison principale de cette separation entre user et admin c'est ca, l'admin gere et controle le systeme, l'utilisateur utilise le systeme.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par ZeroHeure . Évalué à 3.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: nous sommes le 1er avril j'espere...
Posté par gnumdk (site web personnel) . Évalué à 4.
Certe, avec un admin qui gère sont parc Windows, cela ne peut avoir lieu.
Mais je parlais de monsieur tout le monde, dans une famille, si il y'avait des comptes sans privilèges par défaut, ca permettrait de pas voir sa machine en vrac parce que les enfants ont tout péter avec leur MSN à la con.
Donc, j'attend toujours que Microsoft prennent une décision qui fera mal à ses utilisateurs mais qui pour moi sera une bonne chose, les utilisateurs étant peut être moins enclin à installer tout et n'importe quoi si on leur demande un mot de passe à chaque fois.
Je prend l'exemple d'une personne qui a acheté un portable sous Vista, il lui a fallu moins d'un mois pour le pourrir de logiciels dans tous les sens... Avec les machines actuelles, il faut plus d'un mois pour massacrer un Windows mais d'ici 1 an, je sais déjà que cette machine va ramer comme la mort.... Elle avait un PC sous XP avant, j'ai passé une journée à faire un grand nettoyage ce qui a permis de redonner une seconde vie à l'ordi. Il lui a fallu 1 semaine pour tout repéter.
Donc, deux problèmes:
- Par défaut, sous Windows, n'importe qui accédant à la chaise peut faire n'importe quoi
- Et le second: Trop facile d'installer des logiciels (la plupart du temps, les utilisateurs t'assurent qu'ils n'ont rien installé) et surtout les éditeurs sous Windows font bizarrement tous un service pour leur application ce qui assurent la mort de la machine au fil des installations... Souvent quand un XP rame, il suffit de lancer msconfig pour savoir pourquoi
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Et quand je penses que la personne qui a dit "Ah, il faut avoir Internet pour avoir un accès VPN" (elle venait nous demander de régler son problème de VPN) a accès admin à sa machine, j'ai un peu mal au ventre.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Albert_ . Évalué à 2.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par ZeroHeure . Évalué à 2.
c'est vrai sur les windows NT seulement
donc depuis XP pour le grand public
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: nous sommes le 1er avril j'espere...
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par dguihal . Évalué à 3.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par dguihal . Évalué à 4.
Tu dl n'importe quel intalleur de programme
Tu double clique dessus
Vista te demande si tu veux bien faire l'installe
Vista te re-demande si tu veux bien faire l'installe (pourquoi ? On sait pas)
Vista installe le soft.
Jamais vu passer une demande de mot de passe ou quoi que ce soit s'en rapprochant.
Bref comme Fedora mais en pire (ben oui pour la signature on te dis juste que c'est pas signé, mais tu clique OK et basta on continue)
[^] # Re: nous sommes le 1er avril j'espere...
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par dguihal . Évalué à 2.
Ce que je te dis, c'est qu'une installe windows de base telle qu'on la trouve sur un PC du commerce (cad celle utilisée par la majorité des gens) donne les droits d'admin par défaut au compte par défaut que tout le monde utilise.
Donc après dire "Windows n'a jamais permis a un utilisateur simple d'installer qqe chose sur le systeme en global" c'est vrai dans l'absolu, mais complètement a coté de la plaque de ce qui se passe dans la vie réelle
[^] # Re: nous sommes le 1er avril j'espere...
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Olivier (site web personnel) . Évalué à 3.
C'est faux, les Windows 1.x -> 3.x, 95, 98, Me ont toujours autorisés les utilisateurs à installer n'importe quoi sur tout le système. Du moins, dans leur configuration par défaut (sans usage du "policykit").
[^] # Re: nous sommes le 1er avril j'espere...
Posté par vladislav askiparek . Évalué à 1.
http://www.infos-du-net.com/actualite/dossiers/199-6-windows(...)
"Grand Administrateur", ça fait rêver.
Désolé, je n'ai pas testé l'astuce, faute d'OS.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Olivier (site web personnel) . Évalué à 3.
Le root peut connaitre des informations sur le système que l'utilisateur lambda ne connait pas, et l'installation de paquet supplémentaires peut mettre le système à mal.
Récemment, sur Debian Squeeze/Testing j'ai eu des mises à jour qui m'ont causé quelques soucis (GRUB2, Compiz, xorg-server, ...), du fait de spécificités des machines, ou de vieux problèmes bien vicieux enfouis dans le système de fichiers. J'ai mis plusieurs jours à m'en sortir, et heureusement que les machines en question étaient en local, et non pas à distance, sinon cela n'aurait pas été corrigeable facilement.
Un peu plus bas, il est écrit que rien n'empêche un utilisateur de compiler un soft dans son $HOME, voir de s'y installer toute une chaine de compilation dedans. Certes, mais cela demande des connaissances informatiques assez poussées quand même, et en tout cas largement plus que de double-cliquer sur un package.
Le jour où "mes utilisateurs" (famille, amis, collègues de boulot auquel j'installe des Linux perso) aurons atteint un tel niveau de compétence de compilation, alors je les laisserai administrer par eux-même leur machine (de toute façon, ils connaissent déjà leur mot de passe root).
[^] # Re: nous sommes le 1er avril j'espere...
Posté par IsNotGood . Évalué à 4.
L'idée de policykit (utilisé par packagekit) est de donner des privilèges root à l'utilisateur !
Les "vieux admins" vont toujours pester et en "intégriste" dirent que c'est un risque.
Mais autoriser les utilisateurs à installer des programmes de confiance (NB: on ne peut pas installer tout, mais seulement des programmes avec une signature validée !) évite les installations dans $HOME , évite que l'administrateur soit emmerdé toutes les minutes et il peut se concentrer sur des choses plus importantes (par exemple faire un dépot sans les jeux, etc).
C'est le début de cette fonctionnalité, à terme il sera peut-être interdit d'installer un programme suid, d'installer des jeux, etc.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par GeneralZod . Évalué à 6.
Et comme cette fonctionnalité (eh oui, c'en est une) n'a pas été mis en avant que ce soit sur la mailing-list, les releases notes, etc ... ===> paf, on se prends la bonne nouvelle en plein dans la gueule.
Personnellement, ce qui m'a dérangé, ce n'est pas tant la fonctionnalité en elle-même que la gestion cavalière de la question. Un petit nombre de mainteneurs ont introduit un changement majeur dans le comportement et le modèle de sécurité de la distribution sans informer leurs pairs et sans revue externe.
Actuellement, la discussion s'oriente sur la création de profils (paranoïaque, serveur, bureau etc ...) et éventuellement l'intégration à un outil graphique. Le débat dantesque sur la m-l fedora-devel aura eu le mérite de faire avancer les choses reste que beaucoup auraient appréciés qu'il ait lieu avant la sortie de Fedora 12.
En terme d'image, ça ruine (partiellement) le travail qui a été accompli ces dernières années par l'équipe marketing. Oublié le travail monstrueux qui a été fait, oubliée la documentation officielle enrichie et relookée:
http://doc.fedoraproject.org/
Idem pour les efforts de l'équipe marketing pour donner plus de visibilité aux spins:
http://spins.fedoraproject.org/
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Romeo . Évalué à 3.
C'est bien les paquets des dépots ça, non ?
Ca veut dire que le lycéen à la con peut t'installer du grub2 quand tu veux rester en 1... y a 36000 exemples de softs qu'on ne veut pas installer, y a peut etre une bonne raison.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Misc (site web personnel) . Évalué à 3.
La preuve, j'ai des machines ou j'ai lilo et grub d'installé, et curieusement, j'ai pas le sentiment qu'ils se battent pour se nicher sur mon mbr.
Je sais pas ce que tu utilises comme distro, mais j'en connais aucune qui réagit comme tu semble le croire.
Donc je veux bien aussi croire que tu as 36000 exemples, mais bon la, ça fait 1 mauvais exemple, et il reste 35999 potentiels exemples, c'est un peu la poisse de tomber sur le seul mauvais, non, et donc, est ce que tu peux en donner un meilleur ?
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Olivier (site web personnel) . Évalué à 2.
Le truc, c'est que l'installation du paquet demande à l'utilisateur si il veut ou non "chainer" GRUB2. Si tu réponds "non", GRUB2 est installé directement dans le MBR.
Certes, le paquet GRUB1 est toujours présent, et tu peux toujours réinstaller à coup du "/usr/sbin/grub / root (hdx,x) / setup (hdx) / exit". Mais le MBR a été modifié.
[^] # Re: nous sommes le 1er avril j'espere...
Posté par Misc (site web personnel) . Évalué à 2.
# Not a (big) security hole
Posté par Pierre Noguès . Évalué à 0.
[^] # Re: Not a (big) security hole
Posté par Laurent A. . Évalué à 2.
Quant à Samba, ben ça démarrera avec le redémarrage de la machine, ce qui, pour une machine bureautique, arrive fréquemment...
Et là où l'auteur s'enfonce, c'est avec ce passage :
« Et enfin, Fedora c’est plutôt une distribution de test (2 ou 3 nouvelles versions / an), de bureautique et pas trop utilisé en prod, ils ont intégré ce package afin de simplifier la vie des utilisateurs. »
Ou comment faire passer un machin catastrophique comme quelque chose de pas si grave que ça... Une Fedora, c'est deux versions par an et 12 mois avec une version.
En tout cas, les étudiants des salles de TPs pas loin de mon bureau qui lisent ces infos doivent trépigner d'impatience à l'idée des mises à jour des machines \o/
[^] # Re: Not a (big) security hole
Posté par Sufflope (site web personnel) . Évalué à 1.
Non. Les scripts d'init ne sont pas activés lors de l'installation.
[^] # Re: Not a (big) security hole
Posté par IsNotGood . Évalué à 0.
Sans déconner ?
Supposons que Samba a une faille '0-day' qui permet d'avoir les droits root, comment fais-tu pour l'exploiter en l'installant avec packagekit ?
Tu ne peux pas.
[^] # Re: Not a (big) security hole
Posté par GeneralZod . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.