Root
Un article de Wiki de la communauté Mandriva.
Le titre s'affiche avec majuscule en raison d'une particularité de MediaWiki. Mais notez que root ne prend pas de majuscule initiale.
CETTE PAGE EST UNE VERSION RÉVISÉE ET MISE À JOUR DE LA PAGE MAINTENANT OBSOLÈTE DE L'ANCIENNE BASE DE CONNAISSANCES :
http://club.mandriva.com/xwiki/bin/view/KB/AdminAroot ptyxs 10 février 2008 à 11:45 (CET)
[modifier] Introduction à root
Unix et ses clones, au nombre desquels figure GNU/Linux, a été conçu dès l'origine comme un système multi-utilisateur. Lors de sa création, en effet, les ordinateurs personnels n'existaient pas. Unix tournait sur des structures en réseau constituées d'un serveur (un système central ou « mainframe ») auquel étaient connectés de simples terminaux.
Ce système centralisé et avec partage des ressources disponibles nécessitait la présence d'une personne pour le gérer, l'administrateur système, aussi connu sous le nom de superutilisateur (anglais superuser), ou root.
La différence entre des comptes (éventuellement multiples) de « simple utilisateur », d'un côté et un unique compte de superadministrateur, de l'autre, s'est maintenue même dans des emplois de GNU/Linux destinés à des « stations de travail » (des ordinateurs personnels) utilisés essentiellement par un seul utilisateur : et cela leur donne en fait un degré de sécurité fort remarquable, qui constitue un des attraits de ce système d'exploitation.
Le nom du compte utilisé par le superutilisateur est généralement root, mais, en dépit de ce que vous pourriez croire, cela n'a rien d'obligatoire (attention, tout de même, ne vous amusez pas à changer ce nom, car il existe toujours le risque que certains fichiers de configuration y aient recours) ! Ce nom semble venir du fait qu'il est le seul à disposer de l'accès en lecture/écriture sur l'ensemble du répertoire racine (= root directory, en anglais) du système (le répertoire /). Ce n'est cependant pas son nom qui lui donne ses privilèges, mais son user ID (son UID), son identifiant d'utilisateur, qui est toujours 0.
Comme vous pourrez le vérifier en tapant ce qui suit en console, si vous êtes déjà connecté comme root (conformément à l'habitude, nous supposons que l'invite de root se termine par un dièse (#)) :
0
cette commande lit le contenu de la variable d'environnement $UID, qui abrite l'identifiant numérique de l'utilisateur actuel (de l'utilisateur « courant », comme on dit en informatique).
Le fichier /etc/passwd assigne toujours l'UID (User ID) 0 au superutilisateur root, comme on peut le vérifier ainsi :
root:x:0:0:root:/root:/bin/bash
en utilisant la commande grep pour n'en retenir que la ligne qui concerne root.
Le fichier système /etc/passwd contient une ligne pour chaque utilisateur du système. Chaque ligne est formée de « cȟamps » séparés par des deux-points. Le premier champ contient le nom de l'utilisateur (ici root) et le troisième champ son identifiant numérique (UID), ici 0).
Le système de permissions pour les fichiers du système Unix a été programmé pour limiter l'accès des utilisateurs normaux aux fichiers système, tout en laissant le titulaire du compte root maître de l'ensemble des permissions sur les fichiers. Etant donné que tout, dans GNU/Linux, se fait à partir de fichiers, root dispose d'un pouvoir total sur tout le système.
[modifier] Utiliser root peut être dangereux
Il est très tentant pour les utilisateurs débutants sous un système de type Unix, spécialement ceux qui ont l'habitude de systèmes d'exploitation (OS) ne gérant pas de système de permissions, de passer outre ce système, en se connectant d'emblée sur le compte root et d'y rester. Cette façon de procéder ne vous procurerait qu'un soulagement momentané ! Il y a en effet beaucoup de bonnes et excellentes raisons, que vous devrez apprendre à connaître, pour effectuer votre travail journalier sur le système avec un compte de simple utilisateur. root, quant à lui, est le compte d'administration du système
Bon, cela peut paraître surprenant au premier abord, mais écoutez-moi bien : vous pouvez vous planter magistralement avec n'importe quel système d'exploitation. Les concepteurs et développeurs de systèmes font de leur mieux pour vous en empêcher. Mais ces mécanismes ne fonctionnent que si vous utilisez le système comme il se doit. Les concepteurs de systèmes d'exploitation de type Unix partent du principe que l'utilisateur root sait exactement ce qu'il fait. Souvenez-vous que lorsqu'Unix a été conçu, les administrateurs étaient les maîtres de réseaux immenses, à une époque où le commun des mortels n'avait jamais entendu parler d'ordinateurs. Pour l'utilisateur root il n'y a pas de filet de protection, pas de message du genre « Êtes-vous vraiment sûr de vouloir faire cela ? », pas de sauvegardes automatiques. Si vous vous plantez sous root, vous vous plantez réellement.
« Voici une petite histoire. Imaginez que vous ayez les fichiers sendmail.cf dans /etc. C'était mon cas, j'étais en train de travailler sur sendmail et je voulais me débarrasser d'un certain nombre de fichiers sendmail.cf.xxx, j'ai alors utilisé la commande rm en tapant ceci :
rm -f sendmail.cf. *
Au début, j'ai été surpris de constater à quel point c'était long d'effacer cette malheureuse dizaine de fichiers. J'ai interrompu l'action et lorsque j'ai vu ce qui était arrivé, il était déjà trop tard. »
(Richard Eiger dans comp.unix.admin)
Vous avez compris ?
L'auteur de cette histoire voulait taper rm -f sendmail.cf.*, mais l'espace supplémentaire introduit par erreur entre le dernier point et l'astérisque a transformé ce qui a été tapé en une commande demandant d'effacer non seulement le fichier sendmail.cf. mais aussi tous les autres fichiers situés à la racine du répertoire courant, répertoire qui en l'occurrence était le répertoire /etc contenant l'ensemble des fichiers de configuration du système... (pour le sens du symbole étoile voir Le shell sans peine#Le joker *).
Vous avez beaucoup plus de chances d'endommager un système Unix en l'utilisant sous root, comme dans notre exemple, que dans un OS de la famille Win32. Dans la mesure où les concepteurs de cet OS savaient qu'il n'y avait pas de permissions à proprement parler et ont donc mis au point d'autres méthodes pour vous protéger vous et votre système.
Travailler le plus souvent sous votre compte de simple utilisateur plutôt que sous root vous protège contre des assaillants agissant sur la Toile ou des utilisateurs malveillants ou maladroits, mais aussi, contre vous-même !!
[modifier] Ceci n'est pas unixien !
A quoi bon utiliser un système d'exploitation différent de celui dont vous avez l'habitude, si c'est pour le forcer à se comporter de la même façon ? Même en mettant de coté le fait que cette stratégie ne marchera pas, que ferez-vous si vous vous retrouvez un jour sur un autre système Unix où vous ne pourrez pas devenir root ? Vous ne vous sentirez jamais chez vous sur Linux tant que vous n'accepterez pas que certaines choses fonctionnent radicalement différemment sur ce système, et ce pour de très bonnes raisons, et non pour vous empoisonner l'existence (bien que parfois ça en ait parfois bougrement l'air ! ;-) ).
[modifier] Sécurité
Tous les processus lancés par root ont les privilèges de root, ce qui signifie qu'ils font à peu près tout ce qu'ils veulent.
Il n'est donc pas nécessaire qu'ils soient lancés par un programme « mal intentionné », comme un virus, un cheval de Troie ou un ver, pour faire du mal. Notez, du reste, que les programmes « mal intentionnés » de ces différents types sont très rares sous Linux (jusqu'à présent).
Faire des erreurs dans le code d'un programme arrive, et vous savez sûrement que sous Linux, qui compte sur l'utilisateur pour être aussi un testeur actif, des programmes encore en phase de test se rencontrent plus souvent que sous Windows, système pour lequel les tests sont habituellement effectués avant qu'un produit ne soit mis en circulation. Cela est possible parce que les programmeurs peuvent compter sur le mécanisme des permissions pour éviter à leur programme de causer des dommages importants. Mais si vous démarrez ces programmes à tester en root, vous n'aurez plus aucune raison justifiable de vous plaindre après coup si votre système « plante ».
Mais il y a plus. Même des programmes parvenus à maturité peuvent contenir des failles de sécurité dues à leur programmation (ce qu'on appelle en anglais des exploits, un terme que vous pourrez rencontrer sur la Toile même dans des textes français), ces erreurs peuvent permettre à un assaillant d'exécuter des commandes conçues par lui-même avec les permissions du programme concerné). Si ce programme s'exécute avec les privilèges du root, vous avez, en quelque sorte, perdu le contrôle au profit de cet intrus très malin.
Travailler en permanence sous root encourage donc les personnes malintentionnées à concevoir des programmes malintentionnés, et finalement, cela nuit non seulement à vous-même, mais à tout l'ensemble des utilisateurs de GNU/Linux.
La règle de base est donc : n'être root que si et seulement si cela est absolument nécessaire pour la tâche à effectuer.
Des mises à jour de sécurité pour les systèmes Mandriva Linux, destinées à corriger les failles, sont régulièrement mises à la disposition des utilisateurs. Ne négligez pas ces ressources, faites régulièrement vos mises à jour, c'est tellement facile avec les outils Mandriva !!
[modifier] Les tâches qui nécessitent les privilèges de root
Bien sûr, il y a des tâches qui nécessitent les privilèges de root, mais il n'est pas nécessaire de les utiliser tous les jours.
Lorsque vous utiliserez des outils comme le Centre de Contrôle Mandriva (CCM), il vous sera automatiquement demandé de saisir le mot de passe root si vous n'êtes pas déjà sous root.
Mais il existe aussi des outils qui vous permettront de revêtir temporairement ou de façon limitée les privilèges de root chaque fois que vous en aurez besoin. Nous en parlerons dans les prochaines sections.
D'une manière générale, il y a seulement deux sortes de tâches qui nécessitent les privilèges de root :
- Effacer ou créer des fichiers et des répertoires dans des répertoires systèmes.
Déplacer des fichiers hors des répertoires systèmes nécessite aussi les privilèges de root, parce que le fichier original est effacé lors de la manipulation.
Par exemple, supposez que, pour personnaliser l'affichage de la commande ls, vous ayez l'idée (une mauvaise idée !!) de déplacer dans votre répertoire personnel le fichier de configuration générale /etc/DIR_COLORS en lui donnant le nom classique de .dir_colors, eh bien, vous n'y parviendrez pas, fort heureusement, tant que vous êtes connecté comme simple utilisateur... Il se passerait en fait ceci (l'opération échoue et un message d'erreur, dont la teneur pourra varier selon la nature précise de la commande, serait affiché) :
[glin@localhost ~]$ mv /etc/DIR_COLORS /home/glin/.dir_colors mv: ne peut enlever `/etc/DIR_COLORS': N'est pas un répertoire
En revanche, vous pourriez facilement, effectuer une copie de ce fichier dans votre répertoire personnel (une, bonne idée, cela, par contre), même en restant simple utilisateur, en utilisant la commande cp sans option, ainsi :
[glin@localhost ~]$ cp /etc/DIR_COLORS /home/glin/.dir_colors
La commande de copie ne modifie pas ici le contenu d'un quelconque répertoire système : elle peut donc rester dans ce cas à la portée du simple utilisateur...
Vous pouvez aussi avoir besoin de passer sous root lors de l'installation de logiciels (par exemple, avec les commandes rpm ou urpmi ou par l'entremise du Centre de Contrôle de Mandriva). Les RPM s'installent généralement dans des répertoires systèmes dans lesquels seul root a le droit d'écriture.
Toutefois, si vous compilez un programme à partir de ses sources, vous pouvez souvent configurer les choses de telle sorte que vous puissiez l'installer et l'exécuter à partir de votre répertoire personnel, et dans ce cas, vous n'avez pas besoin des privilèges du root pour l'installer.
Veuillez noter, en outre, que compiler un programme ne nécessite pas les privilèges de root lorsque cela est fait dans votre répertoire personnel (/home/votre_nom) et ne devrait d'ailleurs pas être effectué en tant que superutilisateur pour des raisons de sécurité.
./configure et make, sont deux commandes à exécuter en tant qu'utilisateur normal. make install doit être effectué sous root pour installer le programme de telle sorte que tous les utilisateurs y aient accès. Voir là-dessus (futur lien) L'installation de logiciel).
- Ecrire dans des fichiers qui sont dans des répertoires systèmes.
Ce type d'opération exige aussi d'être sous root.
Cela sera par exemple le cas si vous éditez un fichier de configuration système, que ce soit à la main ou par l'intermédiaire d'un utilitaire dédié, mais aussi si vous exécutez un programme qui écrit dans les fichiers système comme updatedb.
Veuillez noter, cependant, que beaucoup de logiciels permettent à l'utilisateur d'avoir des fichiers de configuration pour ledit logiciel dans un répertoire situé sous le répertoire utilisateur, vous pourrez modifier ces fichiers de configuration-là sans passer sous root, car ils appartiennent à votre répertoire personnel et non à un répertoire système. (Leur nom commence généralement par un point : .mozilla, .kde etc. Ils sont considérés comme des fichiers « cachés » par certains gestionnaires de fichier).
Une manière de contourner le problème d'écriture dans les fichiers système est de changer les permissions sur les fichiers ou les répertoires dont vous n'êtes pas propriétaire. Mais soyez prudent en la matière… Voir la page du Wiki sur les permissions.
Notez que pour accéder à des fichiers dans les répertoires système, vous n'avez pas besoin d'être root, dans la majorité des cas. Vous pouvez très bien LIRE la plupart des fichiers de configuration et tous les fichiers de documentation en conservant votre identité habituelle de simple utilisateur.
Alors, quels sont donc ces utilitaires qui vous permettent de devenir root à volonté ? Pour le savoir rendez-vous donc à la section suivante.
Pour plus d'informations sur updatedb, que nous avons mentionnée plus haut, tapez :
man updatedbCette commande permet à locate de trouver rapidement un fichier sur la machine.
[modifier] Devenir root grâce à su
[modifier] su
Pour accomplir les tâches administratives dévolues à root, il n'est pas nécessaire (ni souhaitable, du reste !) de vous reconnecter au système, vous devez juste taper :
Mot de passe :
dans une fenêtre du « shell » (une console) et fournir le mot de passe de root.
Une fois ceci fait, vous êtes root et vous pouvez exécuter n'importe quel programme en root, y compris en principe les logiciels disposant d'une interface graphique (ceci seulement si vous êtes sous une console graphique, comme l'utilitaire Konsole de KDE, si vous êtes sous une des consoles texte accessibles par <CTRL+ALT+Fn>, en revanche, vous ne pourrez pas exécuter les applications graphiques).
Vous pouvez retourner ensuite sous votre compte utilisateur en tapant la combinaison de touches <Ctrl-d> (ou en saisissant exit).
Une manière pratique de vous éviter d'ouvrir beaucoup de terminaux virtuels en su, est d'en créer un une fois et de l'utiliser pour toutes les tâches nécessitant le superutilisateur pendant la durée de votre session de travail.
Bien sûr, vous devez être sûr que personne n'a un accès physique à votre machine lors de cette session. En outre, il est recommandé de fermer ce terminal ou de se déconnecter du compte root lorsque vous êtes sur Internet.
[modifier] su -
Lorsque vous passez en root grâce à la commande su, vous aurez sans doute remarqué que vous restez dans le même répertoire de travail qu'auparavant (la commande pwd affiche le répertoire «« dans lequel vous vous trouvez ») :
/home/toto
Mot de passe :
/home/toto
Si vous voulez disposer de l'environnement complet de root, répertoire de travail compris, lorsque vous utilisez la commande su, il suffit de forcer la lecture des fichiers de configuration des shells de connexion /etc/profile et ~/.bash_profile, ainsi :
/home/toto
Mot de passe :
/root
Vous passerez alors automatiquement dans le répertoire de travail de root et, plus généralement, vous serez sûr de disposer ainsi de tout son environnement.
[modifier] su -c
Une autre option très utile de la commande su est -c. Ainsi la ligne :
exécutera la commande "commande" avec les droits de root et reviendra immédiatement après au compte utilisateur.
Vous ne restez ainsi sous root qu'un minimum de temps, diminuant de ce fait les risques d'erreur ultérieure ou d'intrusion.
Le texte de la commande doit être tapé entre guillemets.
Par exemple, imaginez que vous souhaitiez éditer, sous root, avec l'éditeur de texte Kate, le fichier de configuration de la console /etc/DIR_COLORS, en procédant comme suit, vous serez sûr qu'une fois Kate refermé vous reviendrez automatiquement sous votre identité de simple utilisateur, au lieu de laisser une console ouverte indéfiniment en root.
Un inconvénient de su -c est que la complétion automatique ne marche pas quand vous tapez le contenu de commande.
Une première simplification :
On peut cependant contourner le problème en tapant d'abord la commande à exécuter - la complétion sera alors disponible - et ensuite seulement su -c.
Si, par exemple, vous avez créé à un certain moment un fichier root /etc/mongrosessai.txt, et si, étant sous votre identité de simple utilisateur, vous voulez l'effacer, il est alors préférable de taper d'abord quelque chose comme : rm /e<TAB>mong<TAB> (en faisant usage de la complétion qui est accessible à ce stade) et d'ajouter ensuite su -c en tête de ligne quand vous avez complètement fini de taper la commande.
N'oubliez pas d'ajouter les guillemets ("") autour de la commande à exécuter.
Un peu compliqué ? (souvenez-vous tout de même que vous pouvez aller en début de ligne, dans le shell, à l'aide de la combinaison de touche <Ctrl-a> et en fin de ligne avec <Ctrl-e>).
Une seconde simplification :
Vous pouvez simplifier cette procédure un peu tortueuse en ajoutant une bonne fois pour toutes cette ligne dans le fichier /etc/inputrc :
"\C-x": "\C-e\"\C-asu -c \""
Ceci fait, après avoir relancé le serveur X, ou ouvert une console texte (<CTRL+ALT+Fn>), tapez simplement, sur la ligne de commande, la commande que vous souhaitez exécuter sous root (en usant des fonctions de complétion automatique si nécessaire), puis faites <CTRL x+ENTREE> et vous verrez que vous exécuterez ainsi su -c "commande".
Notre exemple de tout à l'heure peut maintenant devenir ce qui suit.
- tapez tout d'abord :
quand vous avez fini ne tapez pas <ENTREE> immédiatement, mais tapez au clavier : <Ctrl-x>+<ENTREE> et vous obtenez automatiquement :
Mot de passe :
Magique !
Pour ceux qui aiment vraiment comprendre (sautez ces explications si vous êtes pressé !), dans la ligne de code
"\C-x": "\C-e\"\C-asu -c \""
que vous venez de placer dans votre inputrc, notez d'abord que "\C" signifie <Ctrl> (la touche Contrôle de votre clavier).
Cette ligne doit être comprise ainsi :
« Remplacez ce qui se trouve à gauche des deux-points (il s'agira de ce que vous avez réellement tapé, qui est fourni à la commande par le <Ctrl-x> que vous avez lancé au clavier) par ce qui est entre guillemets à droite des deux-points. »
Lorsque vous tapez ENTREE, le système effectue le remplacement.
La partie à droite des deux-points fait appel aux commandes d'édition de la ligne de commande <CTRL-a> (aller en début de ligne) et <CTRL-e> (aller en fin de ligne), voir là-dessus Le shell sans peine#Editer la ligne de commande.
Ainsi, (nous supposons que vous avez tapé kate /etc/DIR_COLORS) :
- le curseur va d'abord en fin de ligne (exécution du \C-e)
- un guillemet est inséré (\"), nous avons donc : kate /etc/DIR_COLORS"
- le curseur va en début de ligne (exécution du \C-a), et se retrouve donc devant la commande
- on insère maintenant ce qui manque (su -c "), ce qui donne su -c "kate /etc/DIR_COLORS"
- la commande est exécutée
et voilà...
Sur le fichier de configuration /etc/inputrc vous pourrez consulter cette page de la Linux Gazette no 55 à compléter par la section sur Readline de la page de man de bash (man bash).
[modifier] su -p
Cette commande semble être d'un emploi peu courant. Les débutants pourront sauter sans dommage cette section.
Et maintenant, attention, attention, un peu de technique : les valeurs de la variable $PATH peuvent être différentes selon qu'on est simple utilisateur ou bien root. Vous pourriez par exemple avoir ceci (cela peut varier selon ce que vous avez introduit dans vos fichiers de configuration du shell), que vous obtiendrez par la commande echo "$PATH" :
- valeur de $PATH pour un simple utilisateur
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/qt3/bin:/home/toto/bin - valeur de $PATH pour root :
/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/lib/qt3/bin
Vous voyez que dans une telle configuration (vérifiez si la vôtre y ressemble… en faisant echo $PATH sous votre identité puis sous root), pour lancer un fichier exécutable du répertoire /usr/games, l'utilisateur root devra fournir le chemin complet du fichier, sinon le shell affichera simplement not found (pas trouvé). De même, les exécutables qui se trouvent sous /sbin ne sont pas accessibles directement par les comptes utilisateurs : l'utilisateur lambda devra fournir le chemin complet pour exécuter un programme s'y trouvant. En général tout cela est ce qui convient.
Toutefois, si vous voulez vraiment conserver vos variables d'environnement, comme par exemple $PATH, lorsque vous vous connectez sous root, utilisez le paramètre -p ainsi :
su -p
Maintenant, le $PATH de root est le même que celui de l'utilisateur qui a exécuté la commande su. Notez que la variable HOME n'a pas été changée, le HOME de root étant alors celui de l'utilisateur.
L'inconvénient d'une telle façon de faire, c'est que les répertoires qui contiennent les commandes d'administration, comme /sbin/ ne font plus partie du chemin de l'environnement. Vous devez alors fournir le chemin complet pour exécuter ces commandes ou modifier la variable $PATH.
[modifier] Quitter root
Pour quitter root et redevenir simple utilisateur, tapez :
ou plus simple encore : tapez sur le clavier la combinaison de touches <Ctrl-d>.
Pour des raisons de sécurité, on conseille de ne pas laisser inutilement une console ouverte sous root lorsque la machine est connectée à un réseau et notamment à Internet.
[modifier] Navette express AR root <> simple utilisateur
Dans les minutes qui suivent, vous pensez avoir à utiliser plusieurs fois root et entrelarder cela de passages sous votre identité de simple utilisateur ? Et vous n'avez pas envie de retaper encore et encore le mot de passe (forcément long et complexe) que vous avez attribué au superutilisateur ?
Voilà comment faire si vous souhaitez rester sur une seule console et minimiser les périodes où une console reste ouverte en root.
Vous passez en root tout à fait normalement via su :
Mot de passe :
Vous faites toutes vos petites affaires sous root, et quand le moment est venu de repasser en simple utilisateur, au lieu de taper exit (ou <Ctrl-d>) comme d'habitude, vous tapez ceci :
bien long à taper ? le plus souvent vous pourrez vous contenter de sus suivi d'<Echap>, la complétion automatique fera le reste !
Cette commande met l'instance de Bash lancée sous root en sommeil à l'arrière-plan et vous voilà redevenu simple utilisateur.
Vous vous activez comme simple utilisateur, et voilà qu'il vous faut maintenant repasser en root. Cette fois vous réveillez root en tapant simplement fg qui le remet à l'avant-plan (fg = foreground) :
Et vous revoilà root. Vous pourrez ainsi autant de fois que vous voudrez passer de l'un à l'autre à coups de suspend et de fg.
La commande suspend ne fonctionnera pas si vous êtes passé sous root par la commande su -
[modifier] Une version graphique de su : kdesu
kdesu est le moyen fourni par KDE pour exécuter des applications graphiques avec les privilèges de root à partir d'un environnement graphique.
kdesu fonctionnera donc à partir d'une console de l'environnement graphique, comme celle de l'utilitaire Konsole généralement présent sur le bureau de KDE, mais pas sur les consoles « traditionnelles » appelées par <CTRL+ALT+Fn> :
Possible aussi : kdesu -c commande. Dans quelle mesure l'option -c est utile ou nécessaire n'est pas très clair à nos yeux. Merci pour toute info à ce sujet.
Une boîte de dialogue vous demandant le mot de passe de root s'affiche et ensuite le programme est exécuté sous root.
Vous pouvez faire en sorte que tel ou tel programme graphique soit lancé systématiquement sous root via une boîte de dialogue, par l'entremise d'un item du menu principal du système ou d'une icône.
Pour cela, il suffit de créer une entrée dans le menu principal ou de modifier une entrée existante. Faites un clic droit sur le bouton du Menu K, puis un clic gauche sur Editeur de menu. Dans la partie gauche de la fenêtre, naviguez jusqu'à la rubrique correspondant à l'application qui vous intéresse et sélectionnez-la (ou ajoutez-la si elle n'existe pas). Tapez alors : kdesu "commande" dans la rubrique Commande (en remplaçant, évidemment commande par la commande appropriée pour le lancement de l'application !), n'oubliez pas pour finir de cliquer sur le bouton Enregistrer avant de quitter l'Editeur du Menu K, pour que le changement soit bien conservé.
Notez que d'autres environnements graphiques utilisent aussi kdesu, si le paquetage kdebase est installé.
Le programme s'appuie sur le fichier .Xauthority qui se trouve dans le répertoire racine de l'utilisateur ($HOME) pour permettre à l'utilisateur root d'accéder au serveur X. Dans les rares cas où ce fichier serait corrompu, kdesu se planterait. Pour éviter cela, supprimez ou renommez le fichier .Xauthority et redémarrez le système. Cela devrait recréer un fichier .Xauthority correct.
Ce programme est livré avec un fichier d'aide en français : qui devrait être dans /usr/share/doc/HTML/fr/kdesu. Il est au format docbook (XML). Pour l'afficher, utilisez la commande :
Notez qu'une des particularités de kdesu est de proposer une fonction de conservation temporaire du mot de passe limitée à la session en cours. Cette fonction est séduisante, mais constitue, si vous l'activez, un certain affaiblissement de la sécurité de votre système. Voir la discussion sur ce point dans la documentation de kdesu.
[modifier] Un su plus facile à manipuler : sudo
sudo est un outil logiciel hautement sophistiqué mais très facile à utiliser. Il permet aux simples utilisateurs d'effectuer certaines tâches sous root, même lorsqu'ils appartiennent à un réseau de grande taille.
Pour installer la commande sudo sur votre machine, au cas improbable où elle n'y serait pas déjà présente, vous pouvez soit récupérer les sources à partir de la page d'accueil de sudo, soit l'installer à partir de votre DVD Mandriva Linux ou des dépôts de paquetages de logiciels. Les administrateurs réseau et autres personnes férues de sécurité récupèreront les sources pour pouvoir paramétrer les nombreuses options importantes proposées lors de la compilation. Pour tous les autres (moi compris :-)), le RPM fera l'affaire.
Le fichier de configuration de sudo est /etc/sudoers.
Vous pouvez en modifier le contenu avec la commande (à taper sous root) :
Les pages de manuel concernant visudo peuvent être consultées avec la commande :
Il est recommandé de ne pas éditer le fichier sudoers autrement qu'en passant par visudo, commande qui doit être lancée avec les privilèges de root.
visudo ouvre sudoers dans un éditeur de texte.
Par défaut, ce peut être l'éditeur vi. Pour ceux qui ne sont pas familiers avec vi, voici les quelques commandes de base, largement suffisantes pour éditer le fichier :
- i vous met en mode « insertion »
- <ESC>:x (touche Echap, puis les 2 touches : et x) sauve le fichier en cours d'édition et quitte l'éditeur
- <ESC>:q! (touche Echap puis les 3 touches : puis q puis !) quitte l'éditeur sans prendre en compte les modifications éventuelles.
Mais, en fait, vous pouvez parfaitement utiliser un autre éditeur, comme Emacs, en définissant la variable d'environnement $EDITOR de façon appropriée (par exemple en tapant : export EDITOR=/usr/bin/emacs avant d'appeler visudo ou même en mettant une bonne fois pour toutes cette ligne dans votre ~/.bashrc).
Vous trouverez la documentation de base sur le fichier de configuration sudoers en tapant la commande :
Elle est très compacte mais exhaustive. Dans la plupart des cas il pourra suffire de lire la section EXAMPLES.
Un exemple très simple (un peu simplifié en fait...) de fichier /etc/sudoers pour une machine mono-utilisateur pourrait être :
# Host alias specification
# User alias specification
# Cmnd alias specification
Cmnd_Alias RPM = /bin/rpm
Cmnd_Alias SHUTDOWN = /usr/sbin/shutdown
# User privilege specification
root ALL = (ALL) ALL
jim ALL = NOPASSWD: RPM, /bin/tar, SHUTDOWN
Dans les sections d'alias (Host (= machine(s) hôte(s=), User (= utilisateur(s)), Cmnd (= commande(s))), vous pouvez définir des variables qu'il vous sera ensuite possible d'utiliser dans la dernière section, User privilege specification (= spécification des privilèges d'utilisateur).
Dans la ligne qui commence par root et concerne donc le superutilisateur, le premier ALL fait référence aux machines de votre réseau. Vous pouvez associer des sous-ensembles de machines du réseau à des variables que vous pouvez définir dans la section Host alias specification. Si vous êtes sur une machine isolée, c'est évidemment sans importance.
Le second ALL correspond aux identités que pourront revêtir les utilisateurs via sudo (par défaut root).
Le dernier ALL correspond à la liste des commandes qui leur seront accessibles. Pour root bien sûr tout est possible (des ALL partout...) : sur toutes les machines du réseau, root peut assumer les droits de tous les utilisateurs pour toutes les commandes du système...
Dans notre exemple, l'utilisateur jim, quant à lui, pourra revêtir les privilèges de root sur toutes les machines du réseau (qu'il y en ait une ou plusieurs...) mais uniquement pour installer et supprimer des RPM, extraire ou créer des tarballs (des archives tar) et arrêter la machine (rappelez-vous que la commande shutdown ne peut être lancée que sous root). La syntaxe qu'il devra mettre en œuvre pour cela est :
par exemple :
NOPASSWD signifie que jim n'a pas besoin de fournir un mot de passe. Par défaut, en l'absence de NOPASSWD sur la ligne appropriée, sudo, avant d'exécuter la commande, demande le mot de passe du compte de l'utilisateur (comprenez bien que ce qui est demandé est le mot de passe de l'utilisateur qui tape la commande sudo et non de celui dont il revêt temporairement l'identité...). Vous ne devriez utiliser l'option NOPASSWD que si personne d'autre que vous n'a accès à votre machine. Notez aussi la possibilité de limiter la « durée de vie » du mot de passe en tapant dans sudoers la ligne :
passwd_timeout min
où min est une valeur numérique, éventuellement nulle, en minutes, pour préciser la durée pendant laquelle le mot de passe est conservé en mémoire. Une option amusante est :
insults
qui lance une bordée d'insultes à toute personne qui se trompe dans la saisie du mot de passe :-). Il y a de nombreuses autres options relatives à la sécurité que vous devriez prendre en compte si vous travaillez dans un environnement peu sûr.
Pour connaître les droits sudo de l'utilisateur courant, tapez :
pour jim cela donnerait :
User jim may run the following commands on this host:
(root) NOPASSWD: /bin/rpm
(root) NOPASSWD: /bin/tar
(root) NOPASSWD: /usr/sbin/shutdown
jim peut ainsi exécuter plus facilement trois tâches administratives parmi les plus courantes sur sa machine, sans trop compromettre la sécurité de son système.
A noter que toutes les invocations de sudo sont enregistrées dans un journal, sur mon système : /var/log/sudo.log, journal qui n'est lisible que par root...
[modifier] Changer le mot de passe root
Changer le mot de passe root d'un système est aisé lorsqu'on connaît ce fameux mot de passe. Il suffit de taper passwd en tant que root.
Changing password for user root.
Nouveau UNIX mot de passe :Lorsque l'on ne se souvient plus du mot de passe, il est nécessaire de passer par la méthode expliquée dans l'article Modifier les mots de passe même root depuis le démarrage.
Pour des problèmes d'accès à root avec ou sans mot de passe et des questions de sécurité relatives au mot de passe de root, on lira avec fruit ce fil du forum Mandriva : failsafe : plus de mot de passe demandé pour root !
