Re: INN2 authentification

On Thu, 31 Aug 2023 10:34:46, Julien ÉLIE <iulius@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 à
é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 ?

C'est correct. Il y a un bloc auth comme j'ai expliqué à la fin, plus un
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)

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