Journal Sortie de la version finale de Fedora 12 « Constantine »

Posté par  .
Étiquettes :
1
18
nov.
2009
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 .

  • # Amateur de KDE

    Posté par  . Évalué à 6.

    Pour les amateurs de KDE, c'est enfin une version utilisable quotidiennement. Parce que les trois versions précédente ont été très dur...

    De plus, le driver graphique Intel refonctionnant parfaitement, c'est fluide et c'est du bonheur.

    • [^] # Re: Amateur de KDE

      Posté par  . Évalué à 3.

      ah bon ? j'utilise 10h par jour une fedora 11 avec kde, je n'ai pas vu de problème...

      • [^] # Re: Amateur de KDE

        Posté par  (site web personnel) . Évalué à 10.

        Tu travailles trop, c'est pour ça.

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: Amateur de KDE

          Posté par  . Évalué à 9.

          C'est parce qu'il a pas encore réalisé que ce qu'il fait en 10h devrait pouvoir être fait en 6 quand le bureau fonctionne normalement.

          (Mais pourquoi oh pourquoi poster ce journal un mercredi??)

          -----------------------> [ ]

      • [^] # Re: Amateur de KDE

        Posté par  . Évalué à 1.

        Je suis d'accord avec toi : Je suis passé du Fedora 11 entièrement à jour à une Fedora 12 et je n'ai vu strictement aucune différence (sauf l'écran de boot).
        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  . Évalué à -9.

      Pour les amateurs de KDE

      Le pluriel s'impose-t-il vraiment?

      désolé, j'ai pas pu résister...

    • [^] # Re: Amateur de KDE

      Posté par  . É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  (site web personnel) . Évalué à 4.

        J'ai trouvé pas mal de plantages de X depuis qq mois (comparaison pifométrique). Plantages qui n'en sont pas d'ailleurs, X est juste si bien occuppé qu'il ne répond pas. Le pilote graphique semble en cause, mais on finit par trouver le bug avec toutes les cartes. Ensuite ça se résoud tout seul en changeant de noyau.
        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  (site web personnel) . Évalué à 2.

    si vous souhaitez en avant première la css spéciale fedora, vous pouvez l'activer sur
    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  (site web personnel, Mastodon) . Évalué à 2.

      tu gâches la surprise :(
      et le journal aussi d'ailleurs

      • [^] # Re: amateurs de css

        Posté par  (site web personnel) . Évalué à 2.

        qelle surprise ?
        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  (site web personnel) . Évalué à 3.

    En direct de Slashdot "Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges"

    --> http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-L(...)


    Plutôt étrange cette nouvelle fonctionnalité, nan ?

    • [^] # Re: /.

      Posté par  . Évalué à 2.

      t'as ete plus rapide...

      • [^] # Re: /.

        Posté par  (site web personnel) . Évalué à 3.

        Ouais mais tu as fait un effort par rapport à moi en développant là ou je n'ai posté qu'un lien ;).... Malheureusement je ne peux pas supprimer mon post.

        Votez ~Albert_ ;).

    • [^] # Re: /.

      Posté par  . Évalué à 9.

      Plutôt étrange cette nouvelle fonctionnalité, nan ?

      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  (site web personnel) . Évalué à 3.

        Euh, -2 pour *expliquer* la fonctionnalité, y en a ici qui cliquent n'importe comment !

        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  . Évalué à 7.

          Euh, -2 pour *expliquer* la fonctionnalité, y en a ici qui cliquent n'importe comment !

          Je ne poste plus beaucoup, c'est mon score par défaut...

      • [^] # Re: /.

        Posté par  (site web personnel) . Évalué à 3.

        Techniquement, tu peux pourrir le systéme quand même, en installant tout ce qui passe :/

        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  . Évalué à 0.

          est ce que ça ne risque pas de pourrir le menu de tout les utilisateurs ?

          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  (site web personnel) . Évalué à 3.

            Quand je parle de Conflicts et Obsoletes, c'est de savoir qu'il y a un tel tag, et de refuser d'installer le rpm.
            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  . Évalué à 4.

    Vu sur slashdot. Fedora a decide de nous en faire une pas mal. Tout utilisateur peut installer tous logiciels signe sans etre root ou sudo. Les paquets ont beau etre signe c'est a mon avis une enorme c......

    - 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  . Évalué à 2.

      C'est le comportement par défaut ?

    • [^] # Re: nous sommes le 1er avril j'espere...

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      N'importe quel utilisateur peut déjà, sur tout système, installer ce qu'il veut. Suffit de dl les sources et compiler…
      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  (site web personnel) . Évalué à -1.

        Perso, si j'ai une machine pour la famille, je n'installe pas de compilo dessus. Et sans compilateur il fera comment pour compiler son logiciel, en compilant le compilateur ?

      • [^] # Re: nous sommes le 1er avril j'espere...

        Posté par  (site web personnel) . Évalué à 3.

        On peut interdire l'execution de programmes sur une partition avec noexec (voir le manuel de mount).
        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  . Évalué à 2.

          On peut aussi lancer des binaires sans droit d'exécution en passant par /lib/ld-linux.2.so :
          $ /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  (site web personnel) . Évalué à 3.

      > 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

      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  (site web personnel) . Évalué à 2.

        Ben oui, ces neuveux ils vont faire des ./configure et des cmake . -DCMAKE_INSTALL_PREFIX=/usr ;)

        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  . Évalué à 5.

          c'est le systeme d'apres ce que j'ai compris et c'est ca que je trouve carrement debile. C'etait un comportement que je ne supporte pas sur les windows et on va avoir ca sur linux? Non tres mauvaise idee.

      • [^] # Re: nous sommes le 1er avril j'espere...

        Posté par  . Évalué à 3.

        Oui deja mes neveux sont des tanches en informatiques donc le jour ou ils feront un truc pareil je pourrais leur faire confiance de pas me peter tout.

        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  (site web personnel) . Évalué à 3.

          > Oui deja mes neveux sont des tanches en informatiques
          > 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  (site web personnel) . Évalué à 3.

            Je pense qu'un admin un poilcompétent, il teste aussi ce qu'il dit avant de poster sur linuxfr, et il ressort pas des trucs vieux datant de mathusalem :

            # 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  . Évalué à 2.

        $ ./configure --prefix=$HOME/usr

        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  . Évalué à 1.

      Et le pire c'est qu'il n'y a pas de moyen simple pour revenir sur un comportement plus decent semble t'il.

      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  . Évalué à 2.

        Je viens de voir en effet. mais bon d'apres les commentaires ce comportement est fait pour durer et pklalockdown va degager. Le pire dans tout ca c'est que il n'a pas ete prevu de revenir a un comportement normal, que ce comportement a ete assez peu publicite et qu'il a pris un assez grand nombre de personne par defaut.

        • [^] # Re: nous sommes le 1er avril j'espere...

          Posté par  . Évalué à -1.

          Le pire dans tout ca c'est que il n'a pas ete prevu de revenir a un comportement normal,

          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  . Évalué à 3.

            Tu vois c'est amusant mais j'ai dans mon bureau un dev fedora et il administre certains de nos ordis aussi. Je peux te garnatir que meme lui a ete surpris par le nouveau comportement et qu'il etait assez peu content de cela. Hier apres-midi il me disait qu'il attendait une mise a jour de F12 corrigeant cela avant de l'installer pour de bon. Comme quoi si meme au sens de Fedora ils ne sont pas aux courrant...

      • [^] # Re: nous sommes le 1er avril j'espere...

        Posté par  . Évalué à 3.

        Ah tiens d'ailleurs je suis 100% d'accord avec ce commentaire:

        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  . Évalué à 2.

        Bah tiens, et apres les memes vont venir troller sur Windows quand faut modifier la base de registre et creer des cles avec des noms bizarres.

    • [^] # Re: nous sommes le 1er avril j'espere...

      Posté par  . Évalué à 2.

      l 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.

      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  (site web personnel) . Évalué à 2.

        Ce qui correspond bien à ce qu'ils veulent ;)

        • [^] # Re: nous sommes le 1er avril j'espere...

          Posté par  . É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  . Évalué à 2.

            Par defaut cela correspond au minimum aux serveurs fedora non? Du coup tu peux installer un certain nombre de jeux, exemple donne au dessus, que l'admin ne souhaiterait peut etre pas non? Ou pire tu sais que tel logiciel est troue tu l'installes et comme ca tu peux gagner les droits root sur le systeme. Non franchement je trouve ca tres tres moyen niveau securite. De plus etant quelqu'un d'assez coherent, je trouvais ce comportement idiot sous windows et donc je ne vois pas pourquoi je le trouverai bien parceque c'est sous linux.
            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  . Évalué à 1.

              De plus etant quelqu'un d'assez coherent, je trouvais ce comportement idiot sous windows et donc je ne vois pas pourquoi je le trouverai bien parceque c'est sous linux.

              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  (site web personnel) . Évalué à 2.

                Ce qui est faux vu que Windows a toujours donné les droits administrateur par défaut au premier utilisateur créé, ce qui est et reste débile...

                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  . Évalué à 2.

                  Le fait qu'un compte soit admin ou pas n'a absolument rien a voir avec le fait de laisser un utilisateur quelconque installer des softs globalement sur le systeme. Dans un des cas, le systeme fonctionne en suivant l'architecture de securite prevue, dans l'autre, on cree un trou beant dans cette architecture.

                  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  (site web personnel) . Évalué à 3.

                    <ironie facile>donc Microsoft fait une très très grosse bêtise depuis des années ?</ironie facile>

                    "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  (site web personnel) . Évalué à 4.

                    Je n'ai pas dit le contraire, j'ai juste dit que le reproche que l'on peut faire à Microsoft la dessus est de donner les droits administrateur à l'utilisateur créé lors de l'installation...

                    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  (site web personnel) . Évalué à 2.

                      - Par défaut, sous Windows, n'importe qui accédant à la chaise peut faire n'importe quoi

                      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  . Évalué à 2.

                  pre vista minimum c'etait pas le premier utilisateur mais TOUS les utilisateurs cree lors de l'installation...

              • [^] # Re: nous sommes le 1er avril j'espere...

                Posté par  (site web personnel) . Évalué à 2.

                mais mais mais toi aussi tu manques de mémoire :-)
                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  . Évalué à 3.

                  Je parles evidemment de la lignee NT, les versions precedentes n'avaient meme pas le concept d'admin/user, permettre a un "utilisateur" d'installer des softs etait donc tout a fait normal et pas un trou dans l'architecture de securite du systeme, vu qu'il n'y avait tout simplement pas de securite.

              • [^] # Re: nous sommes le 1er avril j'espere...

                Posté par  . Évalué à 3.

                Tu parles de la série des NT parce qu'a ma connaissance des windows y'a a eu d'autres et pas vraiment sécurisés eux (3.X, 95, 98, ME)

                • [^] # Re: nous sommes le 1er avril j'espere...

                  Posté par  . Évalué à 1.

                  Tout a fait, mais personne n'a jamais essaye de faire croire qu'ils etaient securises, contrairement a Fedora.

                  • [^] # Re: nous sommes le 1er avril j'espere...

                    Posté par  . Évalué à 4.

                    Pour ma part y'a une semaine ou deux j'ai eu l'occasion de mettre les mains dans un vista de base fourni avec un laptop Compaq et la sécuritén' était pas meilleure :

                    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  . Évalué à 1.

                      Je te suggeres d'utiliser un compte utilisateur plutot qu'admin, il est un peu normal qu'on te demande pas le mot de passe admin si t'es logge en tant que tel...

                      • [^] # Re: nous sommes le 1er avril j'espere...

                        Posté par  . Évalué à 2.

                        La n'est pas la question je sais gérer des droits et des groupes sur un Windows merci.

                        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  (site web personnel) . Évalué à 3.

                Windows n'a jamais permis a un utilisateur simple d'installer qqe chose sur le systeme en global.

                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  . Évalué à 1.

                En tout cas, il est possible de supprimer, copier,etc tout et n'importe quoi sous Win7 en tant que simple utilisateur.
                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  (site web personnel) . Évalué à 3.

      Je suis d'accord avec toi, un utilisateur non-root n'a pas à installer un soft dans le "/".

      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  . Évalué à 4.

        Il faut tout de même essayer d'avoir en tête l'idée globale et que ce n'est qu'une premier jet !

        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  . Évalué à 6.

          Le problème c'est que pendant le cycle de développement, les paquets (rawhide) ne sont pas signés donc personne ne s'en est rendu compte.
          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  . Évalué à 3.

          "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 !)"
          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  (site web personnel) . Évalué à 3.

            Bah tant que grub2 reste sur le disque, on s'en fout, je crois pas que grub2 se mette par magie sur le mbr si tu ne lui dis pas de le faire ( ie, si tu lances pas grub-setup, en root ).

            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  (site web personnel) . Évalué à 2.

              Dans le cas de Debian Squeeze/Testing, le paquet de GRUB2 a modifié tout seul le /boot/grub/menu.lst, afin de rajouter une entrée supplémentaire. Celle-ci permet de "chainer" GRUB2 à GRUB1 lors du boot, afin de tester sans risque GRUB2.

              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  (site web personnel) . Évalué à 2.

                Je pense qu'utiliser un exemple basé sur debian pour dire "il y a un probléme chez fedora" est pas non plus un exemple probant. Les politiques sont légerement différentes, dans le sens ou les devs fedora estiment qu'une installation ne doit pas être interactive.

  • # Not a (big) security hole

    Posté par  . Évalué à 0.

    PackageKit n'est pas une grosse faille de sécurité. Cet article explique pourquoi il est difficile de s'en servir pour effectuer une élévation de privilège : http://www.indahax.com/non-classe/fedora12-packagekit-insecu(...)

    • [^] # Re: Not a (big) security hole

      Posté par  . Évalué à 2.

      Article à la noix oui... Des failles « 0-day », comme le monsieur aime dire, ça existe. Il me semble avoir vu plusieurs grosses failles sur le noyau linux ces derniers temps, pas vrai ?

      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  (site web personnel) . Évalué à 1.

        Quant à Samba, ben ça démarrera avec le redémarrage de la machine, ce qui, pour une machine bureautique, arrive fréquemment...

        Non. Les scripts d'init ne sont pas activés lors de l'installation.

      • [^] # Re: Not a (big) security hole

        Posté par  . Évalué à 0.

        Article à la noix oui... Des failles « 0-day », comme le monsieur aime dire, ça existe.

        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  . Évalué à 2.

        suffit de configurer PackageKit ou simplement de le désinstaller.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.