Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
INN2 authentification
2 views
Skip to first unread message
Marc SCHAEFER
Aug 19, 2023, 7:37:48 AM8/19/23
to
Bonjour,
j'authentifie mes utilisateurs avec un script perl qui consulte une base
de données PostgreSQL.
Mais je fais ainsi dans /etc/news/readers.conf:
auth "remoteusers" {
hosts: *
auth: "/usr/bin/sudo -u newsdb /home/newsdb/ADMIN.new/ckpasswd-db.pl"
}
En fait, auparavant, j'utilisais un simple fichier texte format htpasswd
avec auth: "ckpasswd -f /var/lib/news/nnrp-remoteusers/passwd" que je
générais une fois par jour, mais pour rendre les choses plus
interactives et pour mieux confiner par utilisateur, j'interroge
directement la BD.
C'est assez affreux question performance (2 forks par tentative de
connexion).
Comme la documentation INN2 est assez fournie et que je suis flemmard,
existe-t-il une API qui permettrait à INN2 d'interroger un script qui
serait lancé en permanence (par socket par exemple)? Ou carrément de
mettre le code Perl dans l'interprète Perl interne à INN2?
NB: je suis encore avec INN2 2.6.3, migration à 2.6.4, voire 2.7.1
prévue prochainement.
--
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse. Et si vous écrivez souvent des bobards,
je ne vous lirai plus et je recommanderai (NoCeM) de ne plus vous lire.
j'authentifie mes utilisateurs avec un script perl qui consulte une base
de données PostgreSQL.
Mais je fais ainsi dans /etc/news/readers.conf:
auth "remoteusers" {
hosts: *
auth: "/usr/bin/sudo -u newsdb /home/newsdb/ADMIN.new/ckpasswd-db.pl"
}
En fait, auparavant, j'utilisais un simple fichier texte format htpasswd
avec auth: "ckpasswd -f /var/lib/news/nnrp-remoteusers/passwd" que je
générais une fois par jour, mais pour rendre les choses plus
interactives et pour mieux confiner par utilisateur, j'interroge
directement la BD.
C'est assez affreux question performance (2 forks par tentative de
connexion).
Comme la documentation INN2 est assez fournie et que je suis flemmard,
existe-t-il une API qui permettrait à INN2 d'interroger un script qui
serait lancé en permanence (par socket par exemple)? Ou carrément de
mettre le code Perl dans l'interprète Perl interne à INN2?
NB: je suis encore avec INN2 2.6.3, migration à 2.6.4, voire 2.7.1
prévue prochainement.
--
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse. Et si vous écrivez souvent des bobards,
je ne vous lirai plus et je recommanderai (NoCeM) de ne plus vous lire.
Julien ÉLIE
Aug 30, 2023, 10:33:56 AM8/30/23
to
Bonjour Marc,
> j'authentifie mes utilisateurs avec un script perl qui consulte une base
> de données PostgreSQL.
>
données ? (ckpasswd appelé sans argument va utiliser PAM)
--
Julien ÉLIE
« Quand le dernier arbre aura été abattu, quand la dernière rivière aura
été empoisonnée, quand le dernier poisson aura été pêché, alors on
saura que l'argent ne se mange pas. » (Geronimo)
> j'authentifie mes utilisateurs avec un script perl qui consulte une base
> de données PostgreSQL.
>
> En fait, auparavant, j'utilisais un simple fichier texte format htpasswd
> avec auth: "ckpasswd -f /var/lib/news/nnrp-remoteusers/passwd" que je
> générais une fois par jour, mais pour rendre les choses plus
> interactives et pour mieux confiner par utilisateur, j'interroge
> directement la BD.
>
> C'est assez affreux question performance (2 forks par tentative de
> connexion).
As-tu essayé d'utiliser PAM pour l'authentification sur la base de
> avec auth: "ckpasswd -f /var/lib/news/nnrp-remoteusers/passwd" que je
> générais une fois par jour, mais pour rendre les choses plus
> interactives et pour mieux confiner par utilisateur, j'interroge
> directement la BD.
>
> C'est assez affreux question performance (2 forks par tentative de
> connexion).
données ? (ckpasswd appelé sans argument va utiliser PAM)
--
Julien ÉLIE
« Quand le dernier arbre aura été abattu, quand la dernière rivière aura
été empoisonnée, quand le dernier poisson aura été pêché, alors on
saura que l'argent ne se mange pas. » (Geronimo)
Marc SCHAEFER
Aug 30, 2023, 12:47:04 PM8/30/23
to
On Wed, 30 Aug 2023 14:33:54, Julien ÉLIE <iul...@nom-de-mon-site.com.invalid> wrote:
> As-tu essayé d'utiliser PAM pour l'authentification sur la base de
> données ? (ckpasswd appelé sans argument va utiliser PAM)
Non. Et l'objectif serait d'éviter un fork+exec, idéalement.
> As-tu essayé d'utiliser PAM pour l'authentification sur la base de
> données ? (ckpasswd appelé sans argument va utiliser PAM)
Mais je pourrais déjà optimiser mon truc pour que la BD soit déjà
ouverte par exemple (en interrogeant un web service).
Julien ÉLIE
Aug 31, 2023, 4:34:47 AM8/31/23
to
Bonjour Marc,
>> As-tu essayé d'utiliser PAM pour l'authentification sur la base de
>> données ? (ckpasswd appelé sans argument va utiliser PAM)
>
> Non. Et l'objectif serait d'éviter un fork+exec, idéalement.
>
> Mais je pourrais déjà optimiser mon truc pour que la BD soit déjà
> ouverte par exemple (en interrogeant un web service).
Cela accélérerait effectivement un peu l'authentification.
Est-ce si lent que cela actuellement ?
Il y a aussi le sudo qui consomme un peu de temps dans ta commande "auth".
Et sinon pour répondre à ta question initiale, il n'y a pas de script
lancé en permanence par nnrpd. Une nouvelle instance (fork) de nnrpd est
lancée à chaque nouvelle connexion d'un utilisateur, et tout le
processus d'authentification reprend. nnrpd n'a pas de système autre que
d'exécuter un script à cette fin (que ce soit ckpasswd ou un autre
script dédié Kerberos v5, radius ou autre fait maison comme ckpasswd-db.pl).
Aussi, un exécutable compilé comme ckpasswd sera plus rapide à lancer
qu'un script Perl d'où le fait que je te suggérais d'utiliser ckpasswd
avec un plugin PAM pour PostgreSQL
(https://github.com/pam-pgsql/pam-pgsql qui vient d'ailleurs d'être
packagé dans sid par Debian).
Dans le cas le plus courant sur Alphanet (hors admin par exemple), il
n'y a bien qu'un seul block auth parcouru lançant des scripts
d'authentification ? Ils sont essayés à partir du dernier dans le
fichier readers.conf en remontant jusqu'au premier. L'objectif étant de
ne pas exécuter plusieurs scripts inutilement puisque tu es à la
recherche de performance.
--
Julien ÉLIE
« Les soucis d'aujourd'hui sont les plaisanteries de demain. Rions-en
donc tout de suite. » (Henri Béraud)
>> As-tu essayé d'utiliser PAM pour l'authentification sur la base de
>> données ? (ckpasswd appelé sans argument va utiliser PAM)
>
> Non. Et l'objectif serait d'éviter un fork+exec, idéalement.
>
> Mais je pourrais déjà optimiser mon truc pour que la BD soit déjà
> ouverte par exemple (en interrogeant un web service).
Est-ce si lent que cela actuellement ?
Il y a aussi le sudo qui consomme un peu de temps dans ta commande "auth".
Et sinon pour répondre à ta question initiale, il n'y a pas de script
lancé en permanence par nnrpd. Une nouvelle instance (fork) de nnrpd est
lancée à chaque nouvelle connexion d'un utilisateur, et tout le
processus d'authentification reprend. nnrpd n'a pas de système autre que
d'exécuter un script à cette fin (que ce soit ckpasswd ou un autre
script dédié Kerberos v5, radius ou autre fait maison comme ckpasswd-db.pl).
Aussi, un exécutable compilé comme ckpasswd sera plus rapide à lancer
qu'un script Perl d'où le fait que je te suggérais d'utiliser ckpasswd
avec un plugin PAM pour PostgreSQL
(https://github.com/pam-pgsql/pam-pgsql qui vient d'ailleurs d'être
packagé dans sid par Debian).
Dans le cas le plus courant sur Alphanet (hors admin par exemple), il
n'y a bien qu'un seul block auth parcouru lançant des scripts
d'authentification ? Ils sont essayés à partir du dernier dans le
fichier readers.conf en remontant jusqu'au premier. L'objectif étant de
ne pas exécuter plusieurs scripts inutilement puisque tu es à la
recherche de performance.
--
Julien ÉLIE
« Les soucis d'aujourd'hui sont les plaisanteries de demain. Rions-en
donc tout de suite. » (Henri Béraud)
Marc SCHAEFER
Aug 31, 2023, 5:38:23 AM8/31/23
to
On Thu, 31 Aug 2023 10:34:46, Julien ÉLIE <iul...@nom-de-mon-site.com.invalid> wrote:
> Aussi, un exécutable compilé comme ckpasswd sera plus rapide à lancer
> qu'un script Perl d'où le fait que je te suggérais d'utiliser ckpasswd
> avec un plugin PAM pour PostgreSQL
> (https://github.com/pam-pgsql/pam-pgsql qui vient d'ailleurs d'être
> packagé dans sid par Debian).
C'est effectivement intéressant. Cela éviterait le sudo (qui sert ici à
> Aussi, un exécutable compilé comme ckpasswd sera plus rapide à lancer
> qu'un script Perl d'où le fait que je te suggérais d'utiliser ckpasswd
> avec un plugin PAM pour PostgreSQL
> (https://github.com/pam-pgsql/pam-pgsql qui vient d'ailleurs d'être
> packagé dans sid par Debian).
éviter que l'utilisateur news puisse voir le mot de passe de la base de
données). Toutefois je ne vois pas de notion de persistence de la
connexion à la BD. Une architecture d'un exécutable très simple qui
appelerait un web-service qui lui aurait une connexion persistente à la
DB pourrait toutefois être plus efficace encore.
Cela dit, en mesurant les temps, ce que j'aurais dû faire avant de poser
la question originale:
# bla n'existe pas
news@shakotay:~$ (echo ClientAuthname: bla; echo ClientPassword: truc) | time /usr/bin/sudo -u newsdb /home/newsdb/ADMIN.new/ckpasswd-db.pl
0.05user 0.00system 0:00.07elapsed 73%CPU (0avgtext+0avgdata 13904maxresident)
# schaefer existe
news@shakotay:~$ (echo ClientAuthname: schaefer; echo ClientPassword: truc) | time /usr/bin/sudo -u newsdb /home/newsdb/ADMIN.new/ckpasswd-db.pl
Command exited with non-zero status 1
0.94user 0.00system 0:00.96elapsed 98%CPU (0avgtext+0avgdata 14040maxresident)k
0inputs+0outputs (0major+1478minor)pagefaults 0swaps
On se rend compte que le problème est surtout la vérification du mot de
passe (ça doit être le bcrypt() qui prend du temps CPU à faire ses
boucles, l'overhead de connexion SQL semble négligeable).
Je me rends compte aussi qu'un attaquant peut facilement déterminer si
un utilisateur existe ou non sur le serveur en comparant les temps, mais
bon, cette info se trouve aussi dans chaque article posté ...
La performance comparée de mon script Perl et de ckpasswd semble assez
similaire: si l'on compare le cas où bla n'existe pas (et où la commande
ci-dessus fait un accès DB que ckpasswd ne fait pas):
news@shakotay:~$ (echo ClientAuthname: bla; echo ClientPassword: truc) | time /usr/lib/news/bin/auth/passwd/ckpasswd -f /var/lib/news/nnrp-remoteusers/passwd
ckpasswd: user bla unknown
Command exited with non-zero status 1
0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 2124maxresident)k
0inputs+0outputs (0major+122minor)pagefaults 0swaps
On peut estimer l'overhead de Perl + SQL à 0.07 secondes (sachant que
ckpasswd devrait faire une requête SQL via PAM et apparemment ouvrir
aussi la BD à chaque fois). Sur mon système cela a l'air négligeable.
Donc, à moins de passer à un hashage d'authentification plus classique
et prenant moins de temps, la seconde que j'observais ne pourra pas être
supprimée. Je vais laisser ainsi.
Don't fix it if it isn't broken -- don't optimize it if it does not need
it :)
> Dans le cas le plus courant sur Alphanet (hors admin par exemple), il
> n'y a bien qu'un seul block auth parcouru lançant des scripts
> d'authentification ?
bloc localhost qui n'appelle pas de script.
PS: l'overhead total de l'authentification correcte via NNTP prend
1.069 secondes, l'overhead du lancement de nnrpd semble très
faible; cela prend un peu plus de temps via le proxy car il
ouvre la BD et consulte la configuration NoCeM de l'utilisateur,
suivant les cas cela peut signifier charger une liste de 447'910
Message-IDs répartis en 46 différents NoCeM
(mais là, INN n'est pas impliqué du tout)
Julien ÉLIE
Aug 31, 2023, 7:22:17 AM8/31/23
to
Bonjour Marc,
> 0:00.96 elapsed
> On peut estimer l'overhead de Perl + SQL à 0.07 secondes (sachant que
> ckpasswd devrait faire une requête SQL via PAM et apparemment ouvrir
> aussi la BD à chaque fois). Sur mon système cela a l'air négligeable.
Oui, l'utilisateur n'est plus à 70 ms près...
C'est effectivement, comme tu l'indiques, le temps de vérification du
mot de passe qui est déterminant ici, et proche de 900 ms.
> Don't fix it if it isn't broken -- don't optimize it if it does not need
> it :)
:)
--
Julien ÉLIE
« On ne peut jamais être neutre. Le silence est une opinion. » (Henri
Moret)
> 0:00.96 elapsed
> Donc, à moins de passer à un hashage d'authentification plus
> classique et prenant moins de temps, la seconde que j'observais ne
> pourra pas être supprimée. Je vais laisser ainsi.
Problème résolu donc :)
> classique et prenant moins de temps, la seconde que j'observais ne
> pourra pas être supprimée. Je vais laisser ainsi.
> On peut estimer l'overhead de Perl + SQL à 0.07 secondes (sachant que
> ckpasswd devrait faire une requête SQL via PAM et apparemment ouvrir
> aussi la BD à chaque fois). Sur mon système cela a l'air négligeable.
C'est effectivement, comme tu l'indiques, le temps de vérification du
mot de passe qui est déterminant ici, et proche de 900 ms.
> Don't fix it if it isn't broken -- don't optimize it if it does not need
> it :)
--
Julien ÉLIE
« On ne peut jamais être neutre. Le silence est une opinion. » (Henri
Moret)
0 new messages