Les développeurs ne voulaient pas implémenter le wallet sans mot de passe pour la simple et bonne raison que du coup, tout chiffrement est facile à casser, car au pire il n'y en a pas, et au mieux, il est basé sur des infos connues de tous (nom de user par exemple).
La mémoire PAM ça n'existe pas. Je pensais à un procédé comme dans KDE. Dans le cas où les accès aux sessions passent par PAM (c'est pas le cas de toutes les distros ?), on peut implémenter un module de session qui garde en mémoire volatile (pas sur disque) un certain temps le mot de passe fourni par l'utilisateur, accessible aux applis de cet utilisateur uniquement (du genre, en utilisant le cookie X de session pour l'accès aux infos). Ou plus simplement, un nouveau module PAM exprès pour le wallet de KDE, auquel il suffit de passer les infos (en implémentant use_first_pass dans le module).
Et tu as tort de penser que la seule explication au problème que tu exposes est technique et pas théorique. Je pense que c'est le contraire.
Car la problématique est une problématique de sécurité et d'architecture. Si tu implémentes ton concept, il faut qu'il soit accessible et utilisé par tous les gestionnaires de session, et exprès pour le wallet de KDE, tout en étant raisonnablement sécurisé. Je ne vois que PAM pour faire cela, c'est même fait pour.
Il faut tout de même bien jouer son coup en plaçant le module partout où il faut, parce que sinon, dès que l'utilisateur change son mot de passe : boom, plus d'accès au wallet (mallette).
Du coup, il faut aussi prévoir un "rechiffrement" de la mallette au changement de mot de passe : pas simple tout ça, ça a tous les ingrédients pour échouer.
A part ça, GDM peut lancer des programmes à différents jalons de l'ouverture de session. KDM je sais pas, XDM je ne veux pas savoir ...
[^] # Re: KDE 3.4
Posté par ookaze . En réponse à la dépêche KDE 3.4 RC1. Évalué à 1.
La mémoire PAM ça n'existe pas. Je pensais à un procédé comme dans KDE. Dans le cas où les accès aux sessions passent par PAM (c'est pas le cas de toutes les distros ?), on peut implémenter un module de session qui garde en mémoire volatile (pas sur disque) un certain temps le mot de passe fourni par l'utilisateur, accessible aux applis de cet utilisateur uniquement (du genre, en utilisant le cookie X de session pour l'accès aux infos). Ou plus simplement, un nouveau module PAM exprès pour le wallet de KDE, auquel il suffit de passer les infos (en implémentant use_first_pass dans le module).
Et tu as tort de penser que la seule explication au problème que tu exposes est technique et pas théorique. Je pense que c'est le contraire.
Car la problématique est une problématique de sécurité et d'architecture. Si tu implémentes ton concept, il faut qu'il soit accessible et utilisé par tous les gestionnaires de session, et exprès pour le wallet de KDE, tout en étant raisonnablement sécurisé. Je ne vois que PAM pour faire cela, c'est même fait pour.
Il faut tout de même bien jouer son coup en plaçant le module partout où il faut, parce que sinon, dès que l'utilisateur change son mot de passe : boom, plus d'accès au wallet (mallette).
Du coup, il faut aussi prévoir un "rechiffrement" de la mallette au changement de mot de passe : pas simple tout ça, ça a tous les ingrédients pour échouer.
A part ça, GDM peut lancer des programmes à différents jalons de l'ouverture de session. KDM je sais pas, XDM je ne veux pas savoir ...