Fichier /etc/resolv.conf écrasé à chaque (re)démarrage du système et connection à un réseau

Support Debian
Tags: #<Tag:0x00007f63e41e9f48>
#1

Salut à tous !
Désolé de vous déranger mais… j’ai un petit problème:
A chaque fois que je démarre, que je me déconnecte et reconnecte à un réseau (en général j’utilise le wifi…) le fichier /etc/resolv.conf est écrasé, je m’explique:
J’ai modifié ce fichier auparavant en y mettant mes DNS préféré (2 serveurs DNS le préféré et celui de « secours »), tout fonctionne nikel, mais depuis un certain temps, je ne sais pourquoi… ce ficher est réédité et il y a un truc du genre « ::1 » qui est inscrit, sauf que cette configuration ne fonctionne pas, je suis obligé de rééditer le fichier et d’y remettre mes DNS moi même, j’ai fait le test de changer les permissions:
j’ai changé son propriétaire, au lieu de root j’ai mis mon compte (ou plutôt ma session… pour être plus exacte) en propriétaire (ainsi que mon groupe, ça donnait ça: « terminator:terminator »)
j’ai mis les permissions suivantes: « wxr-xr-xr »

J’ai redémarrer et là SURPRISE ! Le fichier a récupéré ses anciennes permissions, son ancien propriétaire (root) ainsi que la config foireurse « nameserver ::1 »

Merci d’avoir pris la penne de lire ce message et de me répondre :slight_smile:

Cordialement.

#2

C’est un peu normal. Il faut bien mettre à jour ce fichier avec les paramètres DNS associés aux différentes connexions réseau, du moins en principe. Les clients DHCP, les gestionnaires de réseau… font tous ça. Une tentative d’y mettre un peu d’ordre est le paquet resolvconf, à condition que les programmes qui modifient les DNS passent par lui. C’est le cas de dhclient et NetworkManager.

::1 est l’adresse de loopback IPv6. Cela signifie qu’un service DNS récursif local est censé tourner sur la machine elle-même et relayer les requêtes DNS vers d’autres serveurs. S’il ne fonctionne pas, c’est un autre problème.

Et tu croyais vraiment que ça allait empêcher un processus root de le modifier ? Une particularité du superutilisateur (compte root, UID 0) est que les permissions ne s’appliquent pas à lui (sauf cas particulier anormal comme les systèmes de fichiers montés avec FUSE).
Le seul moyen pour empêcher toute modification d’un fichier est soit de monter son système de fichiers en lecture seule (un peu compliqué pour la racine, mais on y viendra), soit de lui appliquer l’attribut « immuable » (chattr +i) si le système de fichiers le permet. Mais c’est sale, ce n’est pas fait pour ça et ça risque de provoquer des erreurs. Il vaudrait mieux identifier le service qui modifie le fichier et est censé faire tourner un serveur DNS local.

#3

Merci d’avoir prit la penne de répondre :))

Mais c’est sale, ce n’est pas fait pour ça et ça risque de provoquer des erreurs. Il vaudrait mieux identifier le service qui modifie le fichier et est censé faire tourner un serveur DNS local.

Comment puis-je faire ? Il y a a-t-il … je n’en sait rien… un fichier log qui répertorie toutes les modifications faites sur les fichiers … ?
Une sorte d’historique ?

#4

Par défaut il n’y a pas d’historique de modification de tous les fichiers. Il y des fichiers de log dans /var/log (syslog, daemon.log, messages), et la sortie de journalctl exécuté en root mais pas sûr que ça dise ce qui modifie le fichier. Peut-être en faisant une corrélation entre la date de modification du fichier et le contenu des logs.

#5

Okay merci,
Je pense avoir réglé partiellement le problème, j’ai fait un coup de « chattr +i » puis j’ai refait la même commande mais avec « -i » comme argument au lieu de « +i », et je n’ai aucun problème, aucune erreur indésirable etc…
et je peux toujours modifier le fichier si je le souhaite.
Je ne sais trop comment… mais le problème a visiblement été résolu:
j’ai supprimé le fichier, je l’ai recréé en déplaçant une copie que j’avais faite de ce même fichier avec ma configuration (avec les mêmes permissions de base…) j’ai fait un coup de « chattr +i /etc/resolv.conf », j’ai ensuite fait « chattr -i /etc/resolv.conf » et maintenant tout fonctionne !

Je n’ai plus aucun problème :))
merci encore de m’avoir aidé et guidé,
passe une bonne journée !

Cordialement

#6

Donc c’est comme si tu n’avais rien fait.

Normal sans l’attribut immuable. Et n’importe quel processus root le peut toujours aussi.