2>&1, >, >>, 2>/dev/null... Si ces symboles dans votre terminal Linux ou macOS vous font autant flipper qu'un regex, respirez un grand coup ! Quand vous aurez lu cet article, vous verrez qu'en fait c'est super simple à comprendre, et en 5 minutes vous saurez enfin ce que vous copiez-collez depuis des années depuis StackOverflow.

En fait, dans les shells Unix (bash, zsh, etc.), y'a 3 canaux de base : stdin (entrée, numéro 0), stdout (sortie normale, numéro 1) et stderr (les erreurs, numéro 2). Tout le reste, de > à 2>/dev/null, découle de ces 3 numéros.

> - Écrire dans un fichier (et tout écraser)

echo "Salut" > fichier.txt

echo "Ligne 2" >> fichier.txt

commande_foireuse 2> erreurs.log

commande > output.log 2>&1

commande &> output.log

find / -name "*.conf" 2>/dev/null

Si vous utilisez Ubuntu 26.04, vous avez peut-être remarqué un truc bizarre dernièrement en tapant votre mot de passe sudo... Ouiiiiii, y'a des petites étoiles qui apparaissent !! Pas de panique, c'est "normal". Enfin, c'est nouveau...

En effet, sudo-rs, la réécriture en Rust de la bonne vieille commande sudo, a décidé d'activer pwfeedback par défaut. En gros, quand vous faites un sudo apt install bidule, au lieu du trou noir habituel, vous voyez maintenant des ***** défiler pendant la saisie du mot de passe. C'est un changement qui casse une convention vieille de 40 ans... et ça, forcément, ça fait du bruit !

Pour rappel, Ubuntu a basculé sur sudo-rs (le remplaçant en Rust du bon vieux sudo en C) depuis la version 25.10. Ça fait partie du même mouvement de réécriture des outils système en Rust, comme les coreutils dont je vous avais parlé. Et la 26.04 vient de "cherry-picker" comme on dit, un patch upstream qui active le feedback visuel par défaut.

Un bug report sur Launchpad ( #2142721 ) est bien sûr arrivé direct, en mode vénère genre "*ÇA FAIT DES DÉCENNIES qu'on n'affiche pas la longueur du mot de passe pour empêcher le shoulder surfing ! C'est quoi ce bordel !!?? *"

Et la réponse des devs : Won't Fix. Circulez les relous !

En fait, leur argument c'est que le bénéfice sécurité est "infinitésimal". Parce que bon, votre mot de passe sudo c'est le même que celui de votre session (celui que vous tapez à l'écran de login, devant tout le monde). Et le bruit des touches trahit déjà la longueur de toute façon. Du coup, ils ont préféré régler le problème UX qui paume les débutants depuis le début des années 80.

D'ailleurs, en 2013 je vous expliquais comment activer ces étoiles manuellement avec sudo visudo (ça date de fou !!) et maintenant c'est l'inverse, faut expliquer comment les virer ! Linux Mint avait d'ailleurs déjà sauté le pas de son côté depuis un moment.

Perso, le truc qui me gonfle c'est pour les tutos vidéo. Quand vous faites un screencast, les astérisques révèlent la longueur de votre mot de passe à tous vos spectateurs. Du coup faut aller reparamétrer chaque machine avant de filmer ou faire du masquage en post prod. C'est pas la fin du monde, mais bon, la flemme...

Alors pour désactiver ces jolies zétoiles :

sudo visudo

Defaults !pwfeedback

Si vous bossez sur des serveurs distants, vous connaissez cette douleur... D'un côté, vous avez votre terminal local aux petits oignons, vos alias, vos plugins... et hop, un petit ssh root@serveur et vous vous retrouvez avec un shell tout pourri, tout basique. Mais c'était sans compter sur Joknarf qui a pondu TheFly , un gestionnaire de plugins shell qui téléporte votre environnement via SSH ou sudo en un instant.

Le principe est pas bête du tout vous allez voir. En fait, vous installez vos plugins et dotfiles dans ~/.fly.d/ sur votre machine, et quand vous lancez flyto user@serveur, tout est empaqueté et envoyé dans /tmp/.fly.$USER/ distant. Prompt perso, alias, fonctions... tout débarque avec vous, un peu comme un sac à dos pour votre shell.

Et le truc bien, c'est que ça ne modifie RIEN sur le serveur distant car tout vit dans /tmp, donc quand vous vous déconnectez... pouf, tout a disparu. Pas de fichier qui traîne, pas de .bashrc modifié donc c'est plutôt safe pour les environnements de prod où vous ne voulez pas laisser de traces.

Ça marche avec bash, zsh et même ksh (pour les nostalgiques). L'installation, c'est un curl en une ligne (à relire comme d'hab), ou alors brew, dnf, paquets .deb... y'a le choix. C'est du pur shell POSIX, donc y'a ZÉRO dépendance externe. Attention par contre, si votre ~/.fly.d/ dépasse 128 Ko, ça risque de ramer sur des connexions un peu lentes.

Ah et y'a aussi flyas pour faire pareil en sudo (attention, ça téléporte aussi vos plugins, donc vérifiez que ça colle avec votre politique de sécu), et flysh pour switcher de shell sans perdre vos réglages. Et puis flypack génère une archive auto-extractible pour avoir un script shell qui s'installe tout seul. Pas mal donc aussi pour partager votre config.

Côté plugins, c'est pas Oh My Zsh avec ses 350+ plugins, mais y'a l'essentiel. Un prompt custom (nerdp), un historique amélioré (redo), de la navigation de répertoires (seedee)... et shell-ng qui regroupe le tout d'un coup. Perso, c'est bien suffisant je trouve.

D'ailleurs si vous êtes du genre à customiser votre shell au millimètre, TheFly s'intègrera bien dans votre workflow. En plus c'est sous licence, open source, et ça tourne sur Linux, macOS et même SunOS (bon ok, je sais, quasi personne utilise SunOS en 2026 mais bon...).

Voilà, comme ça si vous gérez une dizaine de serveurs au quotidien, ça vous fera gagner un paquet de temps !

Amusez-vous bien !

Vous trouvez que votre Linux met 3 plombes à démarrer et vous regardez l'écran de boot défiler en vous demandant ce qui peut bien prendre autant de temps ?

Hé bien bonne nouvelle los amigos del manchos, si vous utilisez une distribution basée sur systemd (comme Debian, Ubuntu, Fedora, Arch, et compagnie), il existe un outil natif déjà installé qui permet de diagnostiquer tout ça : systemd-analyze

Ce truc c'est un peu le médecin légiste de votre démarrage système. Il dissèque chaque étape, identifie les unités qui traînent la patte, et vous permet de comprendre où part votre précieux temps. Pour ceux qui débarquent, systemd est le système d'initialisation adopté par la plupart des distributions modernes, et il permet justement de lancer plein de trucs en parallèle pour gagner du temps.

Pour commencer, la commande de base c'est tout simplement :

systemd-analyze time

systemd-analyze blame

systemd-analyze critical-chain

systemd-analyze plot > boot.svg

sudo systemctl disable nom-du-service

systemctl list-dependencies nom-du-service

systemd-analyze verify /chemin/vers/unite.service

Sous Windows 11/10, les fichiers et dossiers stockés sur un disque NTFS possèdent des autorisations (ACL) qui définissent précisément quels utilisateurs peuvent lire, modifier ou supprimer leur contenu.
Si ces permissions peuvent être configurées via l’interface graphique, PowerShell permet d’aller beaucoup plus loin :
afficher, modifier et automatiser la gestion des droits d’accès à grande échelle.

Grâce aux cmdlets Get-Acl et Set-Acl, vous pouvez :

• afficher les permissions d’un dossier ou d’un fichier,
• ajouter ou retirer des autorisations,
• appliquer les mêmes règles à plusieurs répertoires,
• et même changer le propriétaire d’un dossier bloqué.

Cette approche est particulièrement utile pour les administrateurs ou utilisateurs avancés souhaitant :

• automatiser la gestion des droits sur un serveur ou un poste multi-utilisateurs,
• corriger des problèmes d’accès (“Accès refusé”) sans interface graphique,
• ou déployer des permissions identiques sur plusieurs répertoires partagés.

Pour comprendre en détail la différence entre les autorisations NTFS et les permissions de partage, consultez le guide complet : Autorisations et permissions NTFS : gérer les droits d’accès et le partage de dossiers sous Windows 11/10

Gérer les permissions avec PowerShell

Lister les permissions NTFS (Get-Acl)

Pour afficher la liste complète des autorisations appliquées à un dossier ou fichier :

Get-Acl "C:\Dossier"

Cette commande affiche les ACL (Access Control List) associées à l’élément.
Pour un affichage plus lisible :

Get-Acl "C:\Dossier" | Format-List

Exemple de sortie :

Path : Microsoft.PowerShell.Core\FileSystem::C:\Users\maill
Owner : NT-AUTORITÄT\SYSTEM
Group : NT-AUTORITÄT\SYSTEM
Access : NT-AUTORITÄT\SYSTEM Allow FullControl
VORDEFINIERT\Administratoren Allow FullControl
hp-MAC\maill Allow FullControl
S-1-15-3-65536-599108337-2355189375-1353122160-3480128286-3345335107-485756383-4087318168-230526575 Allow
ExecuteFile, Synchronize
Audit :
Sddl : O:SYG:SYD:P(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;FA;;;S-1-5-21-2373467495-3460344319-1749951908-1001)(A;;0x1
00020;;;S-1-15-3-65536-599108337-2355189375-1353122160-3480128286-3345335107-485756383-4087318168-230526575)

Ajouter une autorisation (AddAccessRule)

Pour accorder une permission spécifique à un utilisateur ou groupe, utilisez Set-Acl avec une nouvelle règle d’accès.

Exemple : donner le Contrôle total à l’utilisateur Paul sur le dossier C:\Partage

$acl = Get-Acl "C:\Partage"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("Paul","FullControl","Allow")
$acl.AddAccessRule($rule)
Set-Acl "C:\Partage" $acl

Explications :

• Get-Acl → récupère les permissions existantes.
• New-Object …FileSystemAccessRule → crée une nouvelle règle d’accès.
• AddAccessRule → ajoute la règle à la liste.
• Set-Acl → applique la nouvelle configuration.

Vous pouvez remplacer "FullControl" par : "Read", "Write", "Modify", "ReadAndExecute" selon les besoins.

Supprimer une autorisation (RemoveAccessRule)

Pour supprimer une règle d’accès existante :

$acl = Get-Acl "C:\Partage"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("Paul","FullControl","Allow")
$acl.RemoveAccessRule($rule)
Set-Acl "C:\Partage" $acl

La suppression nécessite d’utiliser exactement les mêmes paramètres que la règle initiale (même utilisateur, droit et type “Allow” ou “Deny”).

Modifier les permissions d’un dossier et de ses sous-dossiers (Set-Acl)

Pour appliquer les nouvelles autorisations à tous les sous-dossiers et fichiers :

$acl = Get-Acl "C:\Partage"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("Paul","Modify","ContainerInherit,ObjectInherit","None","Allow")
$acl.SetAccessRule($rule)
Get-ChildItem "C:\Partage" -Recurse | Set-Acl -AclObject $acl

Explications :

• Get-ChildItem -Recurse → parcourt récursivement toute l’arborescence.
• ContainerInherit,ObjectInherit → applique la règle aux sous-dossiers et fichiers.

Supprimer toutes les autorisations personnalisées (réinitialiser les ACL)

Pour revenir à la configuration par défaut (héritée du dossier parent) :

icacls "C:\Partage" /reset /T

Cette commande supprime toutes les règles explicites et rétablit les permissions héritées.
Elle est utile pour corriger des erreurs “Accès refusé” ou des droits corrompus.

Changer le propriétaire d’un dossier (SetOwner)

Pour appliquer le changement de propriétaire à tout un dossier et ses sous-dossiers :

$path = "C:\Dossier"
$owner = [System.Security.Principal.NTAccount]"Administrateurs"
Get-ChildItem -Path $path -Recurse -Force | ForEach-Object {
    $acl = Get-Acl $_.FullName
    $acl.SetOwner($owner)
    Set-Acl $_.FullName $acl
}

Cette commande parcourt récursivement tous les fichiers et sous-dossiers.
Elle peut être longue sur un volume contenant de nombreux éléments.

Pour le guide complet sur le changement de propriétaire via l’interface graphique ou la ligne de commande :
Changer le propriétaire d’un dossier sous Windows 11/10

Vérifier le propriétaire actuel

Pour afficher le propriétaire d’un dossier ou fichier :

(Get-Acl "C:\Dossier").Owner

→ Renvoie le nom du compte ou groupe actuellement propriétaire du dossier.

Exemple de script complet : accorder des droits en masse

$users = @("Paul", "Jean", "ServiceRH")
$path = "C:\Dossiers\RH"

foreach ($user in $users) {
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user,"Modify","ContainerInherit,ObjectInherit","None","Allow")
$acl.SetAccessRule($rule)
Set-Acl $path $acl
}

Ce script attribue automatiquement les permissions “Modifier” à plusieurs utilisateurs pour un même dossier.

Tableau récapitulatif des cmdlets PowerShell pour gérer les permissions NTFS

Notes importantes

• Les cmdlets PowerShell (Get-Acl, Set-Acl, etc.) sont plus flexibles et scriptables que les commandes classiques (icacls, takeown).
• Pour toute commande modifiant les ACL, il est recommandé d’exécuter PowerShell en tant qu’administrateur.
• Avant de modifier massivement des droits, vous pouvez sauvegarder les ACL avec : icacls "C:\Dossier" /save C:\backup_acl.txt /T

Bonnes pratiques et précautions

• Ne jamais appliquer un script sans sauvegarder les ACL : icacls "C:\Dossier" /save C:\Backup_ACL.txt /T
• Utiliser la commande Test-Path pour vérifier les chemins avant exécution.
• Toujours tester sur un dossier isolé avant d’appliquer sur un volume complet.
• Exécuter PowerShell en mode Administrateur.

L’article Gérer les permissions NTFS avec PowerShell sur Windows 11/10 est apparu en premier sur malekal.com.