Re: /etc/securetty
Le 14-11-2020, à 20:51:42 +0100, l0f4r0@tuta.io a écrit :
Bonsoir,
14 nov. 2020 à 17:24 de dlist@bluewin.ch:
13 nov. 2020 à 17:18 de s-liste-debian-user-french@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 plein dans le mille ! Je suis sous Testing
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.
Ok, je ne savais pas.
J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3].
En effet, c'est très probablement la même chose chez moi,
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.
Ce qui semble logique en effet.
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
Oui j'ai bien ça.
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...
Bon, je me lance, on verra bien si le monde arrête de tourner après ça.
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.
Tous mes utilisateurs ont un mot de passe.
Merci à toi et très bon dimanche !
Steve
Reply to: