OVH Cloud OVH Cloud

/etc/securetty

7 réponses
Avatar
steve
Bonjour,

Depuis quelques jours j'ai le message suivant qui pollue les logs:

cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory

Après quelques recherches, il semble que ce fichier est un reliquat d'un
passé pas trop lointain qui devait spécifier Í  root sur quel tty il
pouvait se connecter. Or je ne vois pas pourquoi cups en parle et
surtout, je n'arrive plus ͠ imprimer depuis quelques jours. Pas sͻr que
ce soit lié mais sait-on jamais.

Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í 
faire ?

Merci

Steve

7 réponses

Avatar
Bela̓¯d
--000000000000db545f05b3eb43af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Bonjour,
Le fichier est toujours utilis̓© de nos jours , c'est juste que les
applications n'y acc̓¨de pas directement mais a travers Pam. Donc ton
fichier existe bien sur ta config ? Et que contient-il actuellement ?
Le jeu. 12 nov. 2020 17:09, steve a ̓©crit :
Bonjour,
Depuis quelques jours j'ai le message suivant qui pollue les logs:
cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or
directory
Apr̓¨s quelques recherches, il semble que ce fichier est un reliquat d'un
pass̓© pas trop lointain qui devait sp̓©cifier ̓  root sur quel tty il
pouvait se connecter. Or je ne vois pas pourquoi cups en parle et
surtout, je n'arrive plus ̓  imprimer depuis quelques jours. Pas s̓»r que
ce soit li̓© mais sait-on jamais.
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip ̓ 
faire ?
Merci
Steve

--000000000000db545f05b3eb43af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir="auto">Bonjour,<div><br></div><div>Le fichier est toujours utilis̓© de nos jours , c&#39;est juste que les applications n&#39;y acc̓¨de pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 12 nov. 2020 17:09, steve &lt;<a href="mailto:"></a>&gt; a ̓©crit͂ :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bonjour,<br>
<br>
Depuis quelques jours j&#39;ai le message suivant qui pollue les logs:<br>
<br>
cupsd: pam_unix(cups:auth): Couldn&#39;t open /etc/securetty: No such file or directory<br>
<br>
Apr̓¨s quelques recherches, il semble que ce fichier est un reliquat d&#39;un<br>
pass̓© pas trop lointain qui devait sp̓©cifier ̓  root sur quel tty il<br>
pouvait se connecter. Or je ne vois pas pourquoi cups en parle et<br>
surtout, je n&#39;arrive plus ̓  imprimer depuis quelques jours. Pas s̓»r que<br>
ce soit li̓© mais sait-on jamais.<br>
<br>
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip ̓ <br>
faire͂ ?<br>
<br>
Merci<br>
<br>
Steve<br>
<br>
</div>
--000000000000db545f05b3eb43af--
Avatar
steve
Le 12-11-2020, Í  17:18:29 +0100, Belaͯd a écrit :
Bonjour,
Le fichier est toujours utilisé de nos jours , c'est juste que les
applications n'y accède pas directement mais a travers Pam. Donc ton
fichier existe bien sur ta config ? Et que contient-il actuellement ?

Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Avatar
Sébastien NOBILI
Le 2020-11-13 07:55, steve a écrit :
Le 12-11-2020, Í  17:18:29 +0100, Belaͯd a écrit :
Le fichier est toujours utilisé de nos jours , c'est juste que les
applications n'y accède pas directement mais a travers Pam. Donc ton
fichier existe bien sur ta config ? Et que contient-il actuellement
?

Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?

Le fichier existe sur mon système (Buster assez fraÍ®chement installé).
Il appartient au paquet "login".
Sébastien
Avatar
l0f4r0
Bonjour,
12 nov. 2020 Í  17:08 de :
cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
[...]
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í 
faire ?

D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO Í  cause du "No such file or directory" plus haut)
13 nov. 2020 Í  07:55 de :
Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?

Maintenant je comprends que ton /etc/securetty n'existe pas finalement.
Bref tu m'as un peu perdu... ;)
13 nov. 2020 Í  17:18 de :
Le fichier existe sur mon système (Buster assez fraÍ®chement installé).
Il appartient au paquet "login".

Idem ici.
Du coup que donne un simple :
dpkg -l login
Bien cordialement,
l0f4r0
Avatar
Fabien R
On 13/11/2020 07:55, steve wrote:
Le 12-11-2020, Í  17:18:29 +0100, Belaͯd a écrit :
  Bonjour,
  Le fichier est toujours utilisé de nos jours , c'est juste que les
  applications n'y accède pas directement mais a travers Pam. Donc ton
  fichier existe bien sur ta config ? Et que contient-il actuellement ?

Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?

Tu peux avoir l'info par la commande suivante:
apt-file search /etc/securetty
--
Fabien
Avatar
steve
Le 13-11-2020, Í  19:18:00 +0100, a écrit :
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í 
faire ?

D'après cette phrase je comprends que ton /etc/securetty existe (mais
que les droits sont probablement KO Í  cause du "No such file or
directory" plus haut)

Au début, il n'existait pas. J'ai tenté d'en créer un vide avec 'touch
/etc/securetty' en espérant que ça passerait. Ensuite, je me suis aperçu
que ça ne changeait rien, donc je l'ai viré.
13 nov. 2020 Í  07:55 de :
Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?

Maintenant je comprends que ton /etc/securetty n'existe pas finalement.
Bref tu m'as un peu perdu... ;)

Désolé :)
13 nov. 2020 Í  17:18 de :
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
'dpkg --listfiles login' ne me liste pas ce fichier
Idem ici.
Du coup que donne un simple :
dpkg -l login

C'est installé.
J'y perds mon grec…
Merci pour l'intérêt.
Steve
Avatar
steve
Le 14-11-2020, Í  20:51:42 +0100, a écrit :
Bonsoir,
14 nov. 2020 Í  17:24 de :
13 nov. 2020 Í  17:18 de :
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