Je démarre un projet de "logon" avec carte à puce pour Linux ... style GINA
sous Windows.
J'ai étudié quelque peu des logiciels comme gdm et xdm:
J'en ai conclu (peut être à tord):
1) bien qu'il y ai certaines applications avec PAM, cela semble être en
général très propriétaire (de plus PAM est orienté X509 ce qui me pose
problème)
2) la gestion de la fenêtre de connexion est en général codée en dur
3) les gens qui maintiennent ces logiciels ne semblent pas être intéressés
par le problème.
J'aimerais repartir de zéro et développer un gestionnaire de connexion ...
de plus j'aimerais le développer en Python.
Pour commencer, je veux faire très simple:
1) développer un "demon" d'évènement qui se charge de regarder
périodiquement si une carte est insérée dans le lecteur puis prévenir le
gestionnaire de connexion à travers un socket ou autre
2) développer un proto de gestionnaire de connexion qui:
2.a) est appelé par le système au démarrage
2.b) présente une fenêtre au démarrage qui dit "insérez une carte au
tapez "control-alt-del"
2.c) si "control-alt-del" est tapé alors une fenêtre classique du style
champs utilisateur + champs mot de passe apparaît ... puis aller vers 2.e
2.d) si le gestionnaire reçoit un évènement d'insertion alors il fait
apparaître une nouvelle fenêtre dans laquelle l'utilisateur tape son
PIN ... le PIN est présenté à la carte et si tout se passe bien, les
informations de connexion sont lues de la carte
2.e) les informations de connexion sont présentées au système
Les parties qui me bloquent pour l'instant sont 2.a et 2.e (surtout 2.e) .
-- Ya pas pire vieux con, qu'un vieux con qui s'y connais, car non seulement il râle, mais en plus il a raison. --{ LC (connaisseur) in f.m.b.l }--
jean-michel bain-cornu
Bonjour,
Pour commencer, je veux faire très simple: 1) développer un "demon" d'évènement qui se charge de regarder périodiquement si une carte est insérée dans le lecteur puis prévenir le gestionnaire de connexion à travers un socket ou autre 2) développer un proto de gestionnaire de connexion qui: 2.a) est appelé par le système au démarrage 2.b) présente une fenêtre au démarrage qui dit "insérez une carte au tapez "control-alt-del" 2.c) si "control-alt-del" est tapé alors une fenêtre classique du style champs utilisateur + champs mot de passe apparaît ... puis aller vers 2.e 2.d) si le gestionnaire reçoit un évènement d'insertion alors il fait apparaître une nouvelle fenêtre dans laquelle l'utilisateur tape son PIN ... le PIN est présenté à la carte et si tout se passe bien, les informations de connexion sont lues de la carte 2.e) les informations de connexion sont présentées au système
Les parties qui me bloquent pour l'instant sont 2.a et 2.e (surtout 2.e) .
Je suppose que tu as déjà examiné le fonctionnement de inittab, des rc1.d, rc2.d etc, et du lancement d'une session X (s'agit-il bien de cela ?) en fouinant avec google et wikipédia, auquel cas il faudrait que tu précises ce qui te bloque. Pour autant que je sache, xdm (ou équivalent) fait ni plus ni moins qu'un startx (ou équivalent) en donnant les paramètres du terminal X. Est-ce ce que tu veux faire dans ton point 2.e ? Par ailleurs, où est le terminal X ? Est-ce la console du serveur ou un serveur X distant ? Dans ce dernier cas, quel OS est utilisé ? Bref, c'est bien intéressant, mais est-ce que tu peux en dire un peu plus sur la ou les configurations potentielles ?
Bonjour,
Pour commencer, je veux faire très simple:
1) développer un "demon" d'évènement qui se charge de regarder
périodiquement si une carte est insérée dans le lecteur puis prévenir le
gestionnaire de connexion à travers un socket ou autre
2) développer un proto de gestionnaire de connexion qui:
2.a) est appelé par le système au démarrage
2.b) présente une fenêtre au démarrage qui dit "insérez une carte au
tapez "control-alt-del"
2.c) si "control-alt-del" est tapé alors une fenêtre classique du style
champs utilisateur + champs mot de passe apparaît ... puis aller vers 2.e
2.d) si le gestionnaire reçoit un évènement d'insertion alors il fait
apparaître une nouvelle fenêtre dans laquelle l'utilisateur tape son
PIN ... le PIN est présenté à la carte et si tout se passe bien, les
informations de connexion sont lues de la carte
2.e) les informations de connexion sont présentées au système
Les parties qui me bloquent pour l'instant sont 2.a et 2.e (surtout 2.e) .
Je suppose que tu as déjà examiné le fonctionnement de inittab, des
rc1.d, rc2.d etc, et du lancement d'une session X (s'agit-il bien de
cela ?) en fouinant avec google et wikipédia, auquel cas il faudrait que
tu précises ce qui te bloque.
Pour autant que je sache, xdm (ou équivalent) fait ni plus ni moins
qu'un startx (ou équivalent) en donnant les paramètres du terminal X.
Est-ce ce que tu veux faire dans ton point 2.e ?
Par ailleurs, où est le terminal X ? Est-ce la console du serveur ou un
serveur X distant ? Dans ce dernier cas, quel OS est utilisé ?
Bref, c'est bien intéressant, mais est-ce que tu peux en dire un peu
plus sur la ou les configurations potentielles ?
Pour commencer, je veux faire très simple: 1) développer un "demon" d'évènement qui se charge de regarder périodiquement si une carte est insérée dans le lecteur puis prévenir le gestionnaire de connexion à travers un socket ou autre 2) développer un proto de gestionnaire de connexion qui: 2.a) est appelé par le système au démarrage 2.b) présente une fenêtre au démarrage qui dit "insérez une carte au tapez "control-alt-del" 2.c) si "control-alt-del" est tapé alors une fenêtre classique du style champs utilisateur + champs mot de passe apparaît ... puis aller vers 2.e 2.d) si le gestionnaire reçoit un évènement d'insertion alors il fait apparaître une nouvelle fenêtre dans laquelle l'utilisateur tape son PIN ... le PIN est présenté à la carte et si tout se passe bien, les informations de connexion sont lues de la carte 2.e) les informations de connexion sont présentées au système
Les parties qui me bloquent pour l'instant sont 2.a et 2.e (surtout 2.e) .
Je suppose que tu as déjà examiné le fonctionnement de inittab, des rc1.d, rc2.d etc, et du lancement d'une session X (s'agit-il bien de cela ?) en fouinant avec google et wikipédia, auquel cas il faudrait que tu précises ce qui te bloque. Pour autant que je sache, xdm (ou équivalent) fait ni plus ni moins qu'un startx (ou équivalent) en donnant les paramètres du terminal X. Est-ce ce que tu veux faire dans ton point 2.e ? Par ailleurs, où est le terminal X ? Est-ce la console du serveur ou un serveur X distant ? Dans ce dernier cas, quel OS est utilisé ? Bref, c'est bien intéressant, mais est-ce que tu peux en dire un peu plus sur la ou les configurations potentielles ?
jean-michel bain-cornu
En général, si "CtrlAltDel" est tapé, ça fait rebooter le Linux, tu devrais plutôt choisir un truc moins déconcertant, non ? Objection votre honneur : en mode graphique, ctrlAltDel ne fait rien (cf
ubuntu 7). En mode texte, effectivement ça reboote par appel d'un scrip /etc/event.d/control-alt-delete, dans lequel on peut mettre ce qu'on veut évidemment...
A+ jm
En général, si "CtrlAltDel" est tapé, ça fait rebooter le Linux,
tu devrais plutôt choisir un truc moins déconcertant, non ?
Objection votre honneur : en mode graphique, ctrlAltDel ne fait rien (cf
ubuntu 7).
En mode texte, effectivement ça reboote par appel d'un scrip
/etc/event.d/control-alt-delete, dans lequel on peut mettre ce qu'on
veut évidemment...
En général, si "CtrlAltDel" est tapé, ça fait rebooter le Linux, tu devrais plutôt choisir un truc moins déconcertant, non ? Objection votre honneur : en mode graphique, ctrlAltDel ne fait rien (cf
ubuntu 7). En mode texte, effectivement ça reboote par appel d'un scrip /etc/event.d/control-alt-delete, dans lequel on peut mettre ce qu'on veut évidemment...
A+ jm
hg
jean-michel bain-cornu wrote:
Bonjour,
Pour commencer, je veux faire très simple: 1) développer un "demon" d'évènement qui se charge de regarder périodiquement si une carte est insérée dans le lecteur puis prévenir le gestionnaire de connexion à travers un socket ou autre 2) développer un proto de gestionnaire de connexion qui: 2.a) est appelé par le système au démarrage 2.b) présente une fenêtre au démarrage qui dit "insérez une carte au tapez "control-alt-del" 2.c) si "control-alt-del" est tapé alors une fenêtre classique du style champs utilisateur + champs mot de passe apparaît ... puis aller vers 2.e 2.d) si le gestionnaire reçoit un évènement d'insertion alors il fait apparaître une nouvelle fenêtre dans laquelle l'utilisateur tape son PIN ... le PIN est présenté à la carte et si tout se passe bien, les informations de connexion sont lues de la carte 2.e) les informations de connexion sont présentées au système
Les parties qui me bloquent pour l'instant sont 2.a et 2.e (surtout 2.e) .
Je suppose que tu as déjà examiné le fonctionnement de inittab, des rc1.d, rc2.d etc, et du lancement d'une session X (s'agit-il bien de cela ?) en fouinant avec google et wikipédia, auquel cas il faudrait que tu précises ce qui te bloque. Pour autant que je sache, xdm (ou équivalent) fait ni plus ni moins qu'un startx (ou équivalent) en donnant les paramètres du terminal X. Est-ce ce que tu veux faire dans ton point 2.e ? Par ailleurs, où est le terminal X ? Est-ce la console du serveur ou un serveur X distant ? Dans ce dernier cas, quel OS est utilisé ? Bref, c'est bien intéressant, mais est-ce que tu peux en dire un peu plus sur la ou les configurations potentielles ?
Effectivement, j'ai presque mis le doigt sur le problème 2.a (je travaille sur Mandriva 2007.1).
Pour ce premier prototype, le serveur X sera sur le serveur Linux: je vais au plus simple pour l'instant.
C'est donc 2.e qui me bloque le plus ... je suis en train de passer le source de xdm au peigne fin, et c'est pas évident; c'est codé en K&R et des IDEs comme Konqueror ne reconnaissent même plus cette syntaxe ... j'ai ressorti emacs + cscope + ecb pour m'y retrouver.
J'ai l'impression que c'est la couche "Intrinsic" au dessus de "XLib" qui fait le travail du lancement de la nouvelle session, mais je ne suis pas encore très sûr.
hg
jean-michel bain-cornu wrote:
Bonjour,
Pour commencer, je veux faire très simple:
1) développer un "demon" d'évènement qui se charge de regarder
périodiquement si une carte est insérée dans le lecteur puis prévenir le
gestionnaire de connexion à travers un socket ou autre
2) développer un proto de gestionnaire de connexion qui:
2.a) est appelé par le système au démarrage
2.b) présente une fenêtre au démarrage qui dit "insérez une carte au
tapez "control-alt-del"
2.c) si "control-alt-del" est tapé alors une fenêtre classique du style
champs utilisateur + champs mot de passe apparaît ... puis aller vers 2.e
2.d) si le gestionnaire reçoit un évènement d'insertion alors il fait
apparaître une nouvelle fenêtre dans laquelle l'utilisateur tape son
PIN ... le PIN est présenté à la carte et si tout se passe bien, les
informations de connexion sont lues de la carte
2.e) les informations de connexion sont présentées au système
Les parties qui me bloquent pour l'instant sont 2.a et 2.e (surtout 2.e)
.
Je suppose que tu as déjà examiné le fonctionnement de inittab, des
rc1.d, rc2.d etc, et du lancement d'une session X (s'agit-il bien de
cela ?) en fouinant avec google et wikipédia, auquel cas il faudrait que
tu précises ce qui te bloque.
Pour autant que je sache, xdm (ou équivalent) fait ni plus ni moins
qu'un startx (ou équivalent) en donnant les paramètres du terminal X.
Est-ce ce que tu veux faire dans ton point 2.e ?
Par ailleurs, où est le terminal X ? Est-ce la console du serveur ou un
serveur X distant ? Dans ce dernier cas, quel OS est utilisé ?
Bref, c'est bien intéressant, mais est-ce que tu peux en dire un peu
plus sur la ou les configurations potentielles ?
Effectivement, j'ai presque mis le doigt sur le problème 2.a (je travaille
sur Mandriva 2007.1).
Pour ce premier prototype, le serveur X sera sur le serveur Linux: je vais
au plus simple pour l'instant.
C'est donc 2.e qui me bloque le plus ... je suis en train de passer le
source de xdm au peigne fin, et c'est pas évident; c'est codé en K&R et des
IDEs comme Konqueror ne reconnaissent même plus cette syntaxe ... j'ai
ressorti emacs + cscope + ecb pour m'y retrouver.
J'ai l'impression que c'est la couche "Intrinsic" au dessus de "XLib" qui
fait le travail du lancement de la nouvelle session, mais je ne suis pas
encore très sûr.
Pour commencer, je veux faire très simple: 1) développer un "demon" d'évènement qui se charge de regarder périodiquement si une carte est insérée dans le lecteur puis prévenir le gestionnaire de connexion à travers un socket ou autre 2) développer un proto de gestionnaire de connexion qui: 2.a) est appelé par le système au démarrage 2.b) présente une fenêtre au démarrage qui dit "insérez une carte au tapez "control-alt-del" 2.c) si "control-alt-del" est tapé alors une fenêtre classique du style champs utilisateur + champs mot de passe apparaît ... puis aller vers 2.e 2.d) si le gestionnaire reçoit un évènement d'insertion alors il fait apparaître une nouvelle fenêtre dans laquelle l'utilisateur tape son PIN ... le PIN est présenté à la carte et si tout se passe bien, les informations de connexion sont lues de la carte 2.e) les informations de connexion sont présentées au système
Les parties qui me bloquent pour l'instant sont 2.a et 2.e (surtout 2.e) .
Je suppose que tu as déjà examiné le fonctionnement de inittab, des rc1.d, rc2.d etc, et du lancement d'une session X (s'agit-il bien de cela ?) en fouinant avec google et wikipédia, auquel cas il faudrait que tu précises ce qui te bloque. Pour autant que je sache, xdm (ou équivalent) fait ni plus ni moins qu'un startx (ou équivalent) en donnant les paramètres du terminal X. Est-ce ce que tu veux faire dans ton point 2.e ? Par ailleurs, où est le terminal X ? Est-ce la console du serveur ou un serveur X distant ? Dans ce dernier cas, quel OS est utilisé ? Bref, c'est bien intéressant, mais est-ce que tu peux en dire un peu plus sur la ou les configurations potentielles ?
Effectivement, j'ai presque mis le doigt sur le problème 2.a (je travaille sur Mandriva 2007.1).
Pour ce premier prototype, le serveur X sera sur le serveur Linux: je vais au plus simple pour l'instant.
C'est donc 2.e qui me bloque le plus ... je suis en train de passer le source de xdm au peigne fin, et c'est pas évident; c'est codé en K&R et des IDEs comme Konqueror ne reconnaissent même plus cette syntaxe ... j'ai ressorti emacs + cscope + ecb pour m'y retrouver.
J'ai l'impression que c'est la couche "Intrinsic" au dessus de "XLib" qui fait le travail du lancement de la nouvelle session, mais je ne suis pas encore très sûr.
hg
BertrandB
C'est donc 2.e qui me bloque le plus ... je suis en train de passer le source de xdm au peigne fin, et c'est pas évident; c'est codé en K&R et des IDEs comme Konqueror ne reconnaissent même plus cette syntaxe ... j'ai ressorti emacs + cscope + ecb pour m'y retrouver.
J'ai l'impression que c'est la couche "Intrinsic" au dessus de "XLib" qui fait le travail du lancement de la nouvelle session, mais je ne suis pas encore très sûr.
hg Il me semble que les sources de Login.app était plutôt clair peut être
commencer par là même si c'est "moins bien" qu'xdm
C'est donc 2.e qui me bloque le plus ... je suis en train de passer le
source de xdm au peigne fin, et c'est pas évident; c'est codé en K&R et des
IDEs comme Konqueror ne reconnaissent même plus cette syntaxe ... j'ai
ressorti emacs + cscope + ecb pour m'y retrouver.
J'ai l'impression que c'est la couche "Intrinsic" au dessus de "XLib" qui
fait le travail du lancement de la nouvelle session, mais je ne suis pas
encore très sûr.
hg
Il me semble que les sources de Login.app était plutôt clair peut être
commencer par là même si c'est "moins bien" qu'xdm
C'est donc 2.e qui me bloque le plus ... je suis en train de passer le source de xdm au peigne fin, et c'est pas évident; c'est codé en K&R et des IDEs comme Konqueror ne reconnaissent même plus cette syntaxe ... j'ai ressorti emacs + cscope + ecb pour m'y retrouver.
J'ai l'impression que c'est la couche "Intrinsic" au dessus de "XLib" qui fait le travail du lancement de la nouvelle session, mais je ne suis pas encore très sûr.
hg Il me semble que les sources de Login.app était plutôt clair peut être
commencer par là même si c'est "moins bien" qu'xdm
#******************************************************************* #******************************************************************* #******************************************************************* #******************************************************************* class Authentication: """ used to check if the password is OK """ #*************************************************************** #*************************************************************** #*************************************************************** def __init__(self): pass
#*******************************************************************
#*******************************************************************
#*******************************************************************
#*******************************************************************
class Authentication:
"""
used to check if the password is OK
"""
#***************************************************************
#***************************************************************
#***************************************************************
def __init__(self):
pass
#******************************************************************* #******************************************************************* #******************************************************************* #******************************************************************* class Authentication: """ used to check if the password is OK """ #*************************************************************** #*************************************************************** #*************************************************************** def __init__(self): pass