Bonsoir,

14 nov. 2020 à 17:24 de dl...@bluewin.ch:
>> 13 nov. 2020 à 17:18 de s-liste-debian-user-fre...@pipoprods.org:
>>
>>> Le fichier existe sur mon système (Buster assez fraîchement installé).
>>> Il appartient au paquet "login".
>>>
> Pas chez moi:
>
> apt-file search /etc/securetty
> rear: /usr/share/rear/skel/Linux-ia64/etc/securetty
>
Ok, je parie que tu ne fais pas tourner Buster mais plutôt Testing ou Unstable. 
Vrai ?

En effet login ne fournit plus /etc/securetty après Buster [1][2] d'où ta 
sortie de commande différente de la mienne+Sébastien.

J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3].

Auquel cas, vu que le fichier n'est plus fourni, pam devrait arrêter de 
proposer des options qui y font appel au-delà de Buster.

Il semble que la ligne fautive soit dans /etc/pam.d/common-auth, plus 
précisément l'argument "nullok_secure" envoyé au module pam_unix.so.

Je te laisse regarder si t'as bien cette ligne. Sous Buster chez moi c'est la 
suivante :
auth    [success=1 default=ignore]      pam_unix.so nullok_secure

Visiblement, supprimer "nullok_secure" résout le pb d'accès.
Pas certain que ce soit une perte de sécurité dans la mesure où cet argument 
autorise lui-même une certaine largesse...

nullok_secure: The default action of this module is to not permit the user 
access to a service if their official password is blank. The nullok_secure 
argument overrides this default and allows any user with a blank password to 
access the service as long as the value of PAM_TTY is set to one of the values 
found in /etc/securetty.

Bien cordialement,
l0f4r0

[1] : https://packages.debian.org/bullseye/amd64/login/filelist
[2] : https://packages.debian.org/sid/amd64/login/filelist
[3] : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899

Répondre à