Fichier hosts : droits administrateur (2026)

« Permission denied », « Accès refusé », « You don’t have permission to save », la première rencontre avec le fichier hosts est souvent un mur de droits administrateur. Ce n’est pas un bug : c’est une protection de sécurité volontaire. Ce guide explique pourquoi, comment obtenir les droits sur chaque OS, et quoi faire quand l’IT verrouille le fichier.

Comment modifier le fichier hosts en administrateur

Pour modifier le fichier hosts en administrateur, élevez votre éditeur avant d'ouvrir le fichier :

1. Windows : clic droit sur le Bloc-notes (ou le Terminal) → Exécuter en tant qu’administrateur, puis ouvrez C:\Windows\System32\drivers\etc\hosts.
2. Mac : lancez sudo nano /etc/hosts et saisissez votre mot de passe admin.
3. Linux : lancez sudo nano /etc/hosts (ou sudo -e /etc/hosts).
4. Faites vos modifications, puis enregistrez.
5. Si « Accès/Permission refusé » persiste, c'est que l'éditeur n'était pas élevé, fermez-le et rouvrez-le en administrateur.

L'élévation et les erreurs par plateforme sont détaillées ci-dessous.

Guides pratiques par plateforme : pilier multi-OS, Windows, Mac, Linux.

Pourquoi le fichier hosts est protégé

Le fichier hosts est consulté avant le DNS public. Une ligne malveillante :

203.0.113.99 ma-banque.com

… redirigerait votre navigateur vers un serveur de phishing sans modifier le DNS mondial.

Les systèmes d’exploitation classent donc /etc/hosts et son équivalent Windows parmi les fichiers système critiques, modifiables uniquement par :

• root (Unix)
• Administrateur (Windows)
• Processus avec capacité CAP_DAC_OVERRIDE (Linux avancé, rare en desktop)

Comprendre cela transforme la frustration en réflexe : « Je dois élever mes privilèges, pas contourner la sécurité. »

Modèle de permissions par OS

Permissions attendues (Linux/Mac) :

ls -l /etc/hosts
# -rw-r--r-- 1 root root ...

Windows : UAC et élévation

Erreur classique

Ouvrir hosts en double-clic → modifier → Enregistrer → échec silencieux ou boîte d’erreur.

Cause : Bloc-notes standard = utilisateur normal.

Solution :

1. Démarrer → Bloc-notes
2. Clic droit → Exécuter en tant qu’administrateur
3. Confirmer UAC
4. Ouvrir, modifier, enregistrer

Détails : guide Windows, Windows 11.

Controlled Folder Access

Windows Defender peut bloquer même un éditeur admin. Ajoutez une exception ou désactivez temporairement sur poste de dev hors réseau corporate.

Comptes standard en entreprise

Sans droits locaux admin, vous ne pourrez pas modifier hosts. Alternatives :

• VM personnelle de dev
• DNS de staging interne (split-horizon)
• Ticket IT avec liste domaines/IP justifiée

macOS : sudo et applications GUI

Terminal :

sudo nano /etc/hosts

Mot de passe = mot de passe utilisateur admin, pas un mot de passe root séparé.

ToggleHosts et droits admin

Les outils GUI honnêtes demandent aussi l’authentification macOS (Touch ID / mot de passe) car ils écrivent le même fichier protégé. Avantage : backups et validation en plus, guide Mac.

SIP (System Integrity Protection)

SIP protège d’autres zones système ; /etc/hosts reste modifiable avec sudo. Ne désactivez pas SIP pour hosts.

Linux : sudo, groups, et pièges

sudo nano /etc/hosts

Utilisateur doit être dans sudo ou wheel.

Ne jamais faire

sudo chmod 666 /etc/hosts # INTERDIT
sudo chown user:user /etc/hosts # INTERDIT en prod

Vous ouvririez une porte à tout processus utilisateur.

sudo NOPASSWD (CI uniquement)

Pipeline CI sur runner dédié :

deploy ALL=(ALL) NOPASSWD: /bin/cp /tmp/hosts /etc/hosts

Limitez à une commande précise, pas ALL.

Ubuntu : guide Ubuntu.

Lecture vs écriture

Lecture souvent sans admin :

cat /etc/hosts

Windows : Notepad sans admin peut parfois ouvrir en lecture seule.

Écriture = toujours admin. Confusion fréquente chez les débutants.

Sauvegardes avant élévation

Bon réflexe admin :

Windows

copy C:\Windows\System32\drivers\etc\hosts %USERPROFILE%\Desktop\hosts.backup

Mac / Linux

sudo cp /etc/hosts ~/hosts.backup.$(date +%Y%m%d)

Restauration :

sudo cp ~/hosts.backup.20260611 /etc/hosts

Politiques entreprise (GPO, MDM, Intune)

Les organisations verrouillent hosts pour :

• Empêcher contournement filtrage web
• Empêcher malware persistant
• Standardiser résolution interne

Symptômes :

• Fichier se réinitialise au reboot
• Accès refusé malgré admin local
• Entrées disparaissent après sync MDM

Dialogue IT : expliquez le besoin dev (domaines .test locaux), proposez DNS dev interne ou VM.

Sécurité opérationnelle

Modifier hosts avec droits admin est légitime pour le dev. Risques restants :

• Import liste non vérifiée (milliers de lignes)
• Oubli entrée migration → mauvais serveur testé
• Partage d’un hosts « tout-en-un » dans Slack

Analyse complète : est-ce sûr ?.

Checklist admin responsable :

1. Sauvegarde avant changement
2. Une entrée = une raison documentée
3. Date de fin sur entrées temporaires
4. Revue pair pour imports massifs
5. Flush DNS après écriture, syntaxe correcte

Comparatif élévation : ce qui ne suffit PAS

Erreur #1 : sauvegarder une copie modifiée sur le Bureau en croyant l’avoir appliquée.

Workflow équipe : qui a les droits ?

Document partagé : guide complet.

Dépannage « j’ai les droits mais ça ne marche pas »

1. Fichier read-only flag Windows (rare) : attrib -r C:\Windows\System32\drivers\etc\hosts
2. Filesystem RO : live USB recovery
3. Antivirus restauration automatique
4. Éditeur distant (SSH) confond hôte et local
5. Plusieurs lignes conflictuelles, dépannage Mac (concepts transposables)

Audit et traçabilité en entreprise

Les RSSI demandent souvent : « Qui a modifié hosts et quand ? »

Windows : journaux EDR, fichiers Previous Versions sur hosts si VSS actif.

Linux : auditd règle exemple :

-w /etc/hosts -p wa -k hosts_change

Mac : Time Machine ou backups ToggleHosts avec horodatage.

Pour le dev solo, un simple backup daté suffit. Pour la banque, l’audit est non négociable.

Élévation temporaire vs compte admin permanent

Recommandation 2026 : poste principal standard, VM ou second user admin pour expérimentations hosts massives.

Conteneurs et droits : ne confondez pas les namespaces

docker exec -it --user root mycontainer nano /etc/hosts

Vous modifiez le conteneur, pas l’hôte. Les droits root dans Docker ne donnent pas automatiquement les droits sur /etc/hosts de la machine hôte sans montage explicite (déconseillé).

Formation onboarding : script de vérification

Script que les juniors exécutent après leur première modif :

#!/bin/bash
DOMAIN="app.test.local"
if getent hosts "$DOMAIN" | grep -q "127.0.0.1"; then
 echo "OK : $DOMAIN résolu via hosts"
else
 echo "ÉCHEC : vérifier sudo, syntaxe, flush DNS"
 exit 1
fi

Évite 30 minutes de pairing Zoom pour un oubli de sudo.

Conclusion

Les droits administrateur pour le fichier hosts ne sont pas une nuisance, ce sont un garde-fou. Sur Windows, pensez UAC ; sur Mac et Linux, sudo ; en entreprise, dialogue IT plutôt que contournements dangereux.

Une fois les droits acquis, passez aux guides pratiques : pilier, blocage, Windows, Mac avec ToggleHosts.

Sources et ressources externes

• Le fichier hosts expliqué (Wikipédia)
• Page de manuel hosts(5) (man7.org)
• Comment fonctionne le DNS (Cloudflare Learning)