Certaines commandes pratiques sous Linux n'ont pas d'équivalents aussi simples sous Windows. Sudo est un bon exemple même si des alternatives existent, permettant de se faciliter la vie.
Dans les systèmes d'exploitation modernes, plusieurs comptes peuvent être utilisés, chacun avec des droits propres. Ainsi, il peut y avoir des utilisateurs simples, d'autres qui ont accès à certains dossiers/fichiers, parfois en lecture et/ou en écriture, peuvent utiliser ou non telle application, etc. Puis il y a l'administrateur, ou root dans les systèmes UNIX.
Il a en général accès à tout et peut tout faire, notamment installer de nouvelles applications, mettre à jour le système, accéder aux données de configuration, etc. Selon les OS, l'accès à ce compte est géré différemment.
Administrateur sous Linux/Windows : ce n'est pas toujours si différent
Sous Windows par exemple, l'utilisateur principal est en général l'administrateur. Il peut ainsi décider de lancer des applications de manière classique ou avec les droits administrateur, via un clic droit sur l'icône de l'application.
Dans de nombreuses distributions Linux, on trouve une mécanique similaire. Il est ainsi possible de ne pas avoir de compte root actif au profit d'utilisateurs classiques pouvant endosser ce rôle de manière temporaire. Ce qui permet d'éviter une connexion constante à un compte ayant tous les droits, avec les risques que cela comporte.
Dans la pratique, cela passe par l'exécution de la commande sudo (Substitute User Do). Par exemple sous Debian, on peut effectuer la recherche d'un paquet comme un utilisateur classique, mais l'installer avec les droits administrateur :
apt search vlc
sudo apt install vlc
Sous Windows, il n'y a pas d'équivalent si direct en ligne de commandes. Des alternatives doivent donc être utilisées.
Sudo sous Windows : comment faire ?
Car les droits administrateurs ne sont pas toujours nécessaires. On a donc plutôt tendance à utiliser l'invite de commandes de manière classique. Lorsqu'ils le deviennent, on doit lancer une nouvelle fenêtre avec un clic droit pour les activer, un clic de confirmation étant nécessaire (pour l'UAC). Une démarche fastidieuse.
On peut alors opter pour une commande permettant elle aussi d'effectuer une action avec un autre compte, comme celui d'un administrateur. Elle a l'avantage de fonctionner depuis n'importe quel compte du système, mais la syntaxe est un peu longue à retenir. On pourra alors passer par un alias pour se simplifier la vie.
runas /noprofile /user:Utilisateur_Administrateur "commande_à_exécuter"
Avec le temps, certains ont travaillé à de petites applications complémentaires comme Elevate ou des adaptations de sudo pour Windows qui ne sont plus toujours maintenues (voir ici ou là). D'autres ont planché sur une solution multiplateforme comme exec-root de Syed Jafri, qui s'installe comme un module NPM ou Yarn à intégrer à vos applications.
Une solution pratique est le paquet de Jan Hebnes qui est assez complet et s'installe facilement via Chocolatey. On peut en effet l'utiliser sous différentes formes, que ce soit pour lancer une commande non pas en se substituant à un autre compte, mais en endossant les droits administrateur :
sudo commande
Le faire en restant dans le dossier courant, avec ou sans la fenêtre de contexte :
sudo . commande
sudo _ commande
Lancer un invite de commandes avec les droits administrateur :
sudo .
Commentaires (34)
Ca fait un peu solution en plâtre ouvragé et ciselé sur jambe de bois.
Bah comme dit, il y a plusieurs méthode : la commande Windows, l’alias ou le module complémentaire. A chacun de voir ce qu’il préfère ;)
La commande Windows est juste horrible :)
Sinon, j’aime bien tous ces petits dossiers astuces Windows / Linux, est-ce qu’il y a un moyen simple de filtrer les news pour ne voir que ces dossiers ? Genre une catégorie tuto ?
Je vois dans l’image un tag “tuto”, j’ai eu envie de cliquer dessus :)
https://www.nextinpact.com/tutoriels-astuces.htm ;)
C’est dit de manière très implicite, mais sudo ou runas ont aussi comme grand intérêt d’exécuter des actions avec un autre profil utilisateur, pas que root/admin.
Sudo permet ainsi d’exécuter une action au nom d’un utilisateur qui a l’instruction nologin et donc inutilisable en direct.
Exemple : www-data qui est créé avec Apache par défaut sur Debian et qui n’autorise pas la connexion. (et la blinde d’autres comptes de services verrouillés)
Un détail intéressant pour runas aussi, issu de vieux souvenirs mais qui je pense sont toujours d’actu, c’est que ça peut aussi permettre de jouer entre comptes de domaines et comptes locaux sur un Windows.
Avec l’instruction /user:\jeanmichel ou /user:localhost\jeanmichel
Je ne sais pas si vous avez prévu de parler plus en détail du sudoers, mais ça permet aussi de faire des trucs bien puissants et fins pour des gestes d’administration encadrés.
merci !
Ce qui permet d’éviter une connexion constante à un compte ayant tous les droits, avec les risques que cela comporte
Je ne comprends pas la remarque.
Si on crée un compte admin sous Windows ce n’est pas pour l’utiliser en permanence.
D’ailleurs la plupart du temps on peut installer les logiciels directement à partir d’un compte non admin avec un clic droit et “exécuter en tant que”, voire on peut lancer une invite de commandes en tant qu’administrateur.
Ou alors je n’ai pas compris la problématique.
Je suppose que le but est faire tout cela en ligne de commande sans lancer une invite de commande en tant qu’administrateur.
Beaucoup ont encore le sale réflexe de “sudo su - ” et YOLO.
" />
C’est un peu comme ceux qui font direct chmod 777 au moindre problème de droit, une vermine à exterminer.
Autant je plussoie pour le chmod, autant faire un sudo -i / sudo su ça a du sens, quand tu dois faire un grand nombre d’opérations en root.
Typiquement en tant qu’admin sys, sur les serveurs que j’administre, je passe tout mon temps en root, quasiment. Taper sudo à chaque ligne pendant 10 minutes (ou plus), c’est vite gonflant.
+1
Je rejoins Br31zh, avant de m’exterminer*, je serais curieux de savoir en quoi il serait plus pertinent de préfixer toutes les commandes que tu as à faire par un sudo plutôt que de passer en root le temps de passer les commandes avant de revenir à la session utilisateur. La seule justification que je puisse y voir, c’est de conserver les commandes dans son historique bash plutôt que de polluer celui du compte root.
Par contre, j’irais même plus loin sur la possibilité offerte à une utilisateur de faire un « sudo su - », ça veut surtout dire que le système a été troué en amont par l’administrateur — consciemment ou non vu que certaines distributions le font d’office avec un root sans mot de passe — puisque le sudoers autorise quelqu’un à exécuter n’importe quelle commande en tant que root, avec ses identifiants réguliers.
Pour moi, il est ici le véritable danger, pouvoir exécuter directement une commande nécessitant des privilèges particuliers avec les seuls identifiants de l’utilisateur. Dit autrement, un programme malveillant réussissant à obtenir le mot de passe de l’utilisateur fait son escalade de privilèges comme bon lui semble sans se prendre la tête le thread.
Ce qui m’amène à mon « * » du début, en fait j’utilise systématiquement une élévation classique avec su quand c’est possible, « sudo -i »/« sudo su - » c’est vraiment juste pour les cas exceptionnel où je n’ai pas le mot de passe root et c’est généralement temporaire.
En quoi « sudo -i » et « sudo su - » seraient si radicalement différent au point que l’un soit plus à bannir que l’autre ? Même question avec « sudo -s » et « sudo su », que j’aurais pour le coup tendance à délaisser au profit des deux premières.
Je pensais que le “et YOLO” serait suffisamment explicite (avec l’exemple du chmod) pour laisser entendre que la bascule en root ne peut se faire sans maîtrise.
" />
J’ai trop souvent vu des comportements du style passage en root et copier/coller de commandes sans même savoir ce que ça fait… Raison pour laquelle j’aime sortir un petit “t’es sûr de ce que tu fais ?” sur un ton anxiogène quand je vois pratiquer ce genre de chose
C’est sûr que le comportement plus grand dangereux, c’est bien celui de reproduire naïvement des opérations sans même chercher à comprendre ce qu’elles font ni pourquoi les exécuter — et ce n’est d’ailleurs pas valable qu’en informatique.
" />
" />
Un autre exemple de méconnaissance flagrante qui se répand comme une trainée de poudre dans les tutos pour créer un utilisateur MySQL/MariaDB, c’est le « FLUSH PRIVILEGES » juste après un « GRANT […] », « juste au cas où ». Les conséquences sont anecdotiques par rapport au fameux « chmod 777 », mais c’est très symptomatique du « on m’a dit que, et comme ça me permet de, alors je le fais bêtement ».
Sinon faut faire un alias yolo > sudo su -
" />
Je ne suis pas sûr de comprendre la remarque, mais le comportement de la barre des tâches dans les configurations multi-écrans est paramétable, pour reproduire ou non d’un écran à l’autre.
Idéale pour jouer à la roulette russe
" />
J’ai absolument aucune idée de pourquoi tu dis ça, je me suis jamais posé la question. Perso je lance sudo -i parce qu’à une époque j’avais trouvé ça bien de faire directement tout via une seule commande au lieu de lancer su via sudo, mais c’est plus intuitif qu’autre chose.
J’utilise le « -s » pour lancer bash si un petit malin a décidé de mettre autre chose que bash comme shell pour root, sinon.
Justement, il n’y a quasiment rien de paramétrable pour les écrans secondaires, hormis de dire si tu veux faire afficher juste les fenêtres de l’écran, ou l’ensemble des applications. Si tu optes pour la première option, tu as le strict minimum :
Dans le second cas, tu aussi récupères les applications épinglées et… c’est tout !
Peu importe les réglages, tu n’as strictement rien d’autre, aucune barre d’outils additionnelle, pas de zone de notification, ni même le centre de notifications ou tout autre bouton activable via un clic droit sur la barre des tâches (contacts, clavier et pavé tactile). Actuellement, la seule solution à ma connaissance est de passer par des programmes tiers, tous payants, pour véritablement dupliquer à l’identique la barre des tâches sur tous les écrans.
La seule autre chose que l’on puisse faire, c’est de déplacer la barre des tâches complète vers un des écrans secondaires, mais du coup tu récupères la version minimaliste sur ton écran principal tant que tu restes en multi-écrans.
Perso j’utilise Cmder qui permet d’ouvrir de nombreux shell, y compris un linux embed dans Windows.
Et on peut pré-prévoir l’ouverture d’un shell en mode admin. Tout beau, tout propre.
Voir ici ;)
Si vous avez psexec, vous pouvez même ouvrir une ligne de commande pour l’utilisateur System (le VRAI root de Windows) :
runas /user:Administrateur “psexec -s cmd.exe”
Ou si vous avez besoin de pouvoir lancer des fenêtres (par exemple pouvoir lancer regedit en tant que System depuis la ligne de commande), ajouter -i :
runas /user:Administrateur “psexec -i -s cmd.exe”
Ne pas mettre /noprofile pour le runas sinon psexec ne fonctionnera pas.
De rien :-)
Bizarre je ne peux plus éditer mon message.
Je voulais juste ajouter :
C:\WINDOWS\system32>whoami
autorite nt\système