Linux exécutant une commande en tant qu'autre utilisateur. Administrateur dans Ubuntu, ou Qu'est-ce que sudo. options de la commande sudo

Un peu sur sudo lui-même, sur Wikipédia. sudo(Anglais) superutilisateur faire , littéralement « agir au nom de superutilisateur") est un programme développé pour aider l'administrateur système et permet de déléguer certaines ressources privilégiées aux utilisateurs tout en conservant un journal de travail. L'idée principale est de donner aux utilisateurs le moins de droits possible, mais en même temps exactement autant que nécessaire pour résoudre les tâches assignées.

La commande sudo permet aux utilisateurs d'exécuter des commandes en tant qu'utilisateur root ou en tant qu'autres utilisateurs. Les règles que sudo utilise pour décider d'accorder ou non l'accès se trouvent dans le fichier /etc/sudoers ; La langue de leur écriture et des exemples d'utilisation sont décrits en détail dans sudoers(5).

Pour éditer le fichier /etc/sudoers, vous devez utiliser le programme visudo, qui vérifie la syntaxe et évite ainsi les erreurs dans les règles.

Dans la plupart des cas, une configuration appropriée de sudo rend inutile l’exécution en tant que superutilisateur.

Par défaut, le compte root dans Ubuntu est désactivé et root n'a tout simplement pas de mot de passe. Toutes les tâches administratives sont effectuées via sudo. Par défaut, le droit d'exécuter sudo est accordé au premier utilisateur créé lors de l'installation. Tous les autres sont des utilisateurs réguliers par défaut.

Sudo est un outil très flexible qui vous permet de configurer les droits pour effectuer des actions administratives pour chaque utilisateur séparément. Par exemple, autorisez quelqu'un à redémarrer un serveur et donnez à un autre la possibilité de modifier les droits d'accès aux fichiers et aux dossiers. Ouvrez le fichier /etc/sudoers. Cela peut être fait soit en émettant une commande pour ouvrir le fichier dans votre éditeur de texte préféré, par exemple comme ceci :

# nano /etc/sudoers

ou en utilisant l'utilitaire visudo :
# visudo

Cette dernière méthode ouvrira le fichier /etc/sudoers dans l'éditeur par défaut de l'utilisateur, ou si aucun n'est spécifié, alors dans l'éditeur vi. L'avantage de cette méthode est que lors de l'enregistrement du fichier, la conformité à la syntaxe sera vérifiée.

La configuration la plus simple ressemble à ceci :

Valeurs par défaut env_reset

#Spécification des privilèges utilisateur
racine TOUT = (TOUS) TOUS
utilisateur TOUS = (TOUS) TOUS

Cette configuration donne à l'utilisateur tous les droits de l'utilisateur root lors de l'exécution de la commande sudo. Valeurs par défaut env_reset désactive complètement toutes les variables utilisateur lors de l'exécution de commandes en tant que root. C'est une bonne chose du point de vue de la sécurité, mais cela pose parfois des problèmes. Vous pouvez autoriser l'utilisation de variables privées par un groupe ou un individu en ajoutant une ligne comme celle-ci :
Valeurs par défaut :%admin !env_reset

qui enregistrera les variables d'environnement pour tous les utilisateurs du groupe admin, ou :
Valeurs par défaut : utilisateur env_keep = TZ

qui enregistrera la variable TZ pour l'utilisateur utilisateur.

Si le serveur est administré par un groupe de personnes, il est alors logique de procéder comme suit :
%admin TOUS=(TOUS) TOUS

Comme vous pouvez le deviner, cette entrée donne un accès root à tous les membres du groupe d'administrateurs.

Vous pouvez configurer chaque utilisateur spécifique pour avoir accès uniquement à des commandes spécifiques. Par exemple:
utilisateur TOUS = /bin/mount, /bin/kill

donnera aux utilisateurs le droit d'exécuter des commandes de montage et de suppression à partir de n'importe quelle machine, et :
user2 mydebiancomp = /sbin/modprobe

donnera à user2 les autorisations pour exécuter modprobe depuis mydebiancomp. Je pense que la syntaxe est claire :
utilisateur hôte = commande

où la commande est écrite avec le chemin complet. Pour un groupe, tout est similaire, seul le signe « % » est ajouté.

III.Paramètres sudo avancés.

Il est très pratique de créer un groupe d'alias lors de la configuration de sudo. Afin d'éviter de répéter constamment les commandes, les utilisateurs et les hôtes, nous pouvons les regrouper en groupes et définir des règles pour chaque groupe d'alias. Par exemple comme ceci :

Cmnd_Alias command_alias = command1, command2, ... // alias de commande
Host_Alias host_alias = hostname1, hostname2, ... // alias d'hôte
User_Alias user_alias = user1, user2, ... // alias utilisateur

Exécuter une commande pour le compte d'un autre utilisateur est également possible. Par exemple, avec cette entrée :
utilisateur TOUS = (utilisateur2, utilisateur3) /usr/bin/ark

user user peut exécuter la commande ark en tant qu'user2 ou user3, en utilisant la touche u, comme ceci :
$ sudo -u utilisateur2 arche

Par défaut, sudo mémorise les mots de passe pendant 5 minutes. Si vous ne le souhaitez pas, vous pouvez définir une règle distincte pour chaque utilisateur, groupe ou alias, par exemple lorsque :
Valeurs par défaut : user timestamp_timeout = 0

Le mot de passe de l'utilisateur ne sera pas du tout mémorisé, mais si :
Valeurs par défaut : user timestamp_timeout = -1

sera mémorisé pendant toute la durée de disponibilité.

Sudo sans mot de passe est également possible. Il existe une conception similaire pour cela :
utilisateur myubuntucomp = NOPASSWD : /bin/kill

ce qui permettra à l'utilisateur de l'hôte myubuntucomp d'utiliser kill sans demander de mot de passe. Insérez vos propres valeurs, telles que ALL au lieu du nom d'hôte et de la commande, afin que l'utilisateur ne puisse jamais saisir de mot de passe pour exécuter des commandes en tant que root à partir de n'importe quel hôte, mais n'oubliez pas que cela rend le système très vulnérable.

Garde

Des blogs, des blogs, des blogs. Maxim Fuckin en sait beaucoup sur ce sujet.

Carte interactive de la ville d'Orenbourg. Réalisé à l'aide de la technologie Google Maps en utilisant nos propres développements. La ressource est jeune, mais déjà très intéressante et utile.

Paradoxalement, la commande sudo n'empêche pas d'exécuter une session administrateur au sein d'une session utilisateur standard. Parce qu'avec son aide, vous pouvez exécuter la même commande su :

$sudo su

Et c'est même dans Ubuntu, où il n'y a pas de compte root ; plus précisément, il n'y a pas de mot de passe par défaut. Mais utiliser sudo le rend inutile même pour la commande su. Mais il n'est pas interdit de définir un mot de passe superutilisateur - après tout, pour ce faire, il suffit de donner la commande

$ mot de passe sudo

afin d'utiliser su de la manière habituelle à l'avenir. Et même, si vous le souhaitez, connectez-vous en tant que root lors de votre inscription dans le système.

Cependant, ici aussi, la commande sudo propose une méthode « idéologiquement correcte », et même pas une seule. Ce sont les options -s et -i, qui prolongent, bien que de manière légèrement différente, l'action de la commande sudo pour une durée indéfinie, jusqu'à ce que la « session secondaire » soit terminée avec la commande exit.

L'option -s, lors de l'ouverture d'une session root secondaire, préserve toutes les variables d'environnement de l'utilisateur d'origine. Cependant, si vous y ajoutez l'option -H, alors ces variables seront relues à partir des fichiers de profil du répertoire personnel de l'administrateur, c'est-à-dire /root, comme lors du démarrage d'une instance de shell interactive. Cependant, le répertoire qui était courant au moment où la commande a été saisie ne changera pas, pas plus que l'apparence de l'invite de ligne de commande.

L'option -i reproduit complètement l'environnement racine, en lançant son shell de commande en tant que shell de connexion. Bien entendu, dans ce cas, le répertoire courant devient également /root et l'invite de ligne de commande prend la forme décrite dans la variable correspondante dans le fichier de profil du shell de l'administrateur (dans bash - PS1).

En pratique, la différence entre les deux formes d'obtention de droits d'administrateur permanents n'est pas grande, surtout dans bash. Mais dans zsh, avec les paramètres appropriés des fichiers de profil, vous pouvez, si vous le souhaitez, obtenir un environnement sensiblement différent dans chacun de ces cas. Certes, la question de savoir dans quelle mesure l'utilisateur en a besoin est une grande question. Mais le fait que lors de l'utilisation des options -H, être en mode administratif permanent n'apparaisse en aucune façon extérieurement est semé d'erreurs. Et rend l'utilisation de l'option -i préférable dans la plupart des cas.

À propos, les capacités de sudo ne se limitent pas à l'exécution de commandes en tant qu'administrateur : en spécifiant l'option -u username, elles peuvent être exécutées au nom de l'utilisateur dont le login est spécifié comme valeur. Cela peut être utile lors de l'affichage ou de la copie des fichiers point et des répertoires point d'un autre utilisateur, qui ne sont souvent lisibles et modifiables que par le propriétaire.

D'ailleurs, la commande sudo peut être exécutée de manière à demander le mot de passe de l'utilisateur sous le nom duquel la commande sera exécutée (par exemple, l'administrateur), et non celui qui demande ses droits. Il existe une option -targetpw pour cela. Et pour rendre permanente l'exigence du mot de passe root, il suffit de définir, par exemple, un alias comme

Alias sudo-targetpw

Exiger que le mot de passe root soit saisi lors de l'exécution de sudo est le comportement par défaut dans certaines distributions, par exemple, comme on dit, dans Suse.

La commande sudo a beaucoup plus d'options - j'ai répertorié ci-dessus uniquement celles que je devais utiliser. Le reste est facile à rechercher dans man sudo. Parmi ceux qui ne sont pas répertoriés, je mentionnerai également l'option -b, qui demande d'exécuter la commande « supervision » en arrière-plan. Cela peut être utile lors de l'exécution d'actions à long terme, par exemple lors de la copie d'images USB sur une clé USB avec la commande dd.

Comme nous venons de le voir, la commande sudo donne à l'utilisateur des pouvoirs presque illimités pour toute action à l'échelle du système, ainsi que pour manipuler les données utilisateur d'autres personnes. À cet égard, posons-nous les questions suivantes :

si un utilisateur peut obtenir des droits d'administrateur via la commande sudo, et
peut-il effectuer toutes les démarches administratives en l'utilisant ?

Si nous parlons de la famille Ubuntu, dans laquelle ce mécanisme a été utilisé pour la première fois « hors des sentiers battus », alors « hors des sentiers battus », la réponse à la première question sera négative, à la seconde - positive. En général, cela dépend des paramètres du programme sudo, qui sont décrits dans le fichier /etc/sudoers. Et vous pouvez y définir des règles qui permettent uniquement à certains utilisateurs d'exécuter certaines commandes. En résumé cela ressemble à ceci :

Nom d'utilisateur hôte = commande

Ici, comme vous pouvez le deviner, username est le nom de l'utilisateur pour lequel cette règle est définie, host est le nom de la machine à partir de laquelle il peut utiliser cette règle, command est une commande spécifique que cet utilisateur est autorisé à utiliser. cette machine. La commande doit être donnée avec un chemin absolu complet (c'est-à-dire /sbin/fdisk, pas fdisk). Le champ de description de la commande peut inclure plusieurs valeurs séparées par des virgules, par exemple :

Nom d'utilisateur ALL = /sbin/fdisk,/bin/mount

Dans Ubuntu, les règles par défaut pour l'accès des utilisateurs aux privilèges administratifs sont décrites comme suit :

# Spécification des privilèges utilisateur root ALL=(ALL) ALL # Les membres du groupe admin peuvent obtenir les privilèges root %admin ALL=(ALL) ALL

Autrement dit, l'utilisateur root, comme prévu, peut exécuter n'importe quelle commande à partir de n'importe quel hôte. Mais seuls les utilisateurs membres du groupe admin (analogue au groupe wheel dont il a été question) peuvent obtenir ses droits. Un utilisateur créé lors d'une installation normale devient automatiquement membre de ce groupe - et dispose donc de tous les droits d'administration sans aucun réglage supplémentaire. Toutefois, les autres utilisateurs dont les comptes seront créés ultérieurement sont privés de ce privilège. À moins, bien sûr, qu’ils soient spécifiquement inclus dans le groupe administrateur.

Dans d'autres distributions qui n'utilisent pas sudo par défaut, vous devrez modifier son fichier de configuration - le même /etc/sudoers mentionné ci-dessus.

Le fichier /etc/sudoers est un fichier texte normal et, par conséquent, il peut être modifié dans n'importe quel éditeur de texte (ou, par exemple, en utilisant ed ou sed). Cependant, il existe un certain risque de gâcher quelque chose (à cause de fautes de frappe ordinaires), voire de bloquer complètement votre accès aux privilèges de superutilisateur. Bien entendu, ces situations peuvent être corrigées, par exemple en redémarrant en mode mono-utilisateur. Cependant, il vaut mieux ne pas les frapper. Et par conséquent, un moyen plus fiable de modifier /etc/sudoers serait d'utiliser un utilitaire spécialement conçu à cet effet - visudo.

L'utilitaire visudo ne fait rien de surnaturel - il ouvre simplement /etc/sudoers dans un éditeur de texte décrit par la variable superutilisateur EDITOR (si elle n'est pas définie, ce sera à nouveau le vi classique - d'où le nom) et vous permet de l'éditer de la manière habituelle, puis quittez l'éditeur en enregistrant les résultats en utilisant ses moyens standard. Cependant, avant cela, l'exactitude du résultat de l'édition est vérifiée. Et si une violation de la syntaxe acceptée pour /etc/sudoers est détectée, un avertissement correspondant est émis. Après quoi vous pouvez revenir à l'édition, refuser les modifications apportées, ou encore les accepter (bien entendu, sous votre responsabilité personnelle).

L'utilitaire visudo ne garantit pas un succès d'édition à 100 %. Puisqu’il vérifie uniquement la cohérence de la syntaxe, mais pas « l’exactitude des règles elles-mêmes ». Autrement dit, si une erreur est commise lors de la spécification du chemin d'accès à la commande requise pour une règle donnée, cette commande via sudo ne fonctionnera pas.

Cependant, en réalité, cela semble généralement beaucoup plus simple et pas du tout effrayant. Ainsi, dans Fedora 11, dans l'exemple de configuration /etc/sudoers, il me suffisait de décommenter la ligne

%roue TOUT=(TOUS) TOUS

pour donner à l'utilisateur du groupe spécifié (et je m'y suis inclus à l'avance, comme décrit dans) tous les droits accordés à l'administrateur. En même temps, vous pourriez vous donner la possibilité d'utiliser sudo sans mot de passe. Cela nécessiterait de décommenter la ligne

# %wheel ALL=(TOUS) NOPASSWD : TOUS

Mais je me suis limité à faire durer le mot de passe plus longtemps en ajoutant (la ligne initialement manquante

Valeurs par défaut timestamp_timeout=10

où la valeur du délai d'attente est spécifiée en minutes. Au fait, si vous le changez à zéro -

Valeurs par défaut timestamp_timeout=0

alors le mot de passe sera demandé à chaque fois que vous utiliserez la commande sudo.

Vous pouvez au contraire désactiver le timeout de l'action sudo en lui attribuant une valeur négative :

Valeurs par défaut timestamp_timeout=-1

Dans ce cas, le mot de passe ne vous sera demandé qu'au premier appel de cette commande.

Un examen plus attentif du fichier /etc/sudoers révélera facilement des opportunités d'accorder à certains utilisateurs ou groupes uniquement un ensemble limité de droits. Cependant, c’est là que commencent les subtilités de la véritable administration. J'ai simplement privé mon double-expérimentateur d'accès à toute action administrative afin de stopper toutes ses tentatives dans ce domaine. Cependant, même cela ne me permet pas toujours de faire face à lui - tout comme Timur Shaov est incapable de faire face à son héros lyrique.

Depuis l'Antiquité, beaucoup ont été déconcertés par la variété des options de sécurité lors de l'exécution d'opérations avec des privilèges maximaux. Par exemple, dans la documentation officielle d'Ubuntu, il est recommandé d'utiliser quelque chose comme sudo nano comme commande d'édition, et dans de nombreux manuels amateurs (dans le style de « 5 astuces en ligne de commande qui surprendront votre grand-mère ») pour obtenir un shell racine. est suggéré d'écrire sudo su - je vais essayer d'expliquer pourquoi cet état de fait me semble erroné.

Historiquement, le seul moyen universel d'exécuter une commande en tant qu'autre utilisateur sous Unix était d'utiliser le programme su. Lancé sans paramètres, il a demandé le mot de passe du superutilisateur et, en cas de succès, a simplement remplacé le nom d'utilisateur actuel par root, laissant presque toutes les variables d'environnement de l'ancien utilisateur (sauf PATH, USER et quelques autres, voir man su de votre distribution ). Il serait plus correct de l'exécuter en tant que su - auquel cas le shell recevrait également le bon environnement. Avec l'option -c, vous pouvez exécuter la commande : su -c "vim /etc/fstab" .

Dans ce cas, les utilisateurs de confiance devaient se souvenir du mot de passe root, et tous les utilisateurs répertoriés dans le groupe « wheel » (c'est-à-dire dans le groupe dont les membres pouvaient exécuter la commande su et devenir superutilisateur) avaient le même accès illimité à l'ensemble système, ce qui constituait un grave problème de sécurité.

Ensuite, la commande sudo est arrivée et ce fut une avancée décisive. Désormais, l'administrateur peut spécifier une liste de commandes autorisées pour chaque utilisateur (ou groupe d'utilisateurs), des fichiers disponibles pour l'édition, des variables d'environnement spéciales et bien plus encore (toute cette beauté est contrôlée depuis /etc/sudoers, voir man sudoers depuis votre distribution) . Une fois lancé, sudo demande à l'utilisateur son propre mot de passe, pas le mot de passe root. Un shell complet peut être obtenu en utilisant "sudo -i"

Il convient de noter en particulier la commande spéciale sudoedit, qui lance en toute sécurité l'éditeur spécifié dans la variable d'environnement $EDITOR. Avec un schéma plus traditionnel, l'édition des fichiers se faisait à peu près comme ceci :
sudo vi /etc/fstab

Lancé de cette manière, vi a hérité du shell avec des droits illimités et via :! l'utilisateur pouvait exécuter n'importe quelle commande (à moins, bien sûr, que l'administrateur ne s'en soit occupé à l'avance) et ouvrir n'importe quel fichier.

Sudoedit vérifie si cet utilisateur peut modifier un fichier donné, puis copie le fichier spécifié dans un répertoire temporaire, l'ouvre dans un éditeur (qui hérite des droits de l'utilisateur, pas de root), et après édition, si le fichier a été modifié, le copie avec des précautions particulières.

Sur les distributions basées sur Debian, l'utilisateur root n'a pas de mot de passe ; à la place, toutes les actions administratives doivent être effectuées via sudo ou son équivalent graphique gksudo. Étant un remplacement complet de su , sudo devrait être la seule commande permettant de basculer entre les utilisateurs, cependant, comme cela a été dit au début, ce n'est pas le cas pour le moment et pour une raison quelconque, tout le monde invente des séquences sauvages de sudo, su, vi et des tirets.

Par conséquent, je suggère à chacun de se rappeler une fois pour toutes :

Après la première publication de cette note, plusieurs questions m’ont été posées. À partir des réponses, nous avons réussi à créer une mini-FAQ.

Q : Comment puis-je utiliser sudo pour faire su -c "echo 1 > /etc/privileged_file" ? sudo echo 1 /etc/privileged_file se plaint de « autorisation refusée »
R : Cela se produit car seule la commande echo est exécutée avec des droits élevés et le résultat est redirigé vers le fichier avec les droits d'un utilisateur normal. Pour ajouter quelque chose à privilèged_file, vous devez exécuter la commande suivante :
$ écho 1| sudo tee -a fichier_privilégié >/dev/null
Ou devenez temporairement root :
$ sudo -i # echo 1 > fichier_privilégié # exit $
Q : sudo -i est plus long que su - , mais il ne semble y avoir aucune différence entre eux, pourquoi en imprimer plus ?
R : sudo présente plusieurs avantages qui valent la peine de taper quelques caractères supplémentaires :

par défaut, sudo enregistre toutes les activités des utilisateurs dans le canal syslog authpriv (en règle générale, le résultat est placé dans le fichier /var/log/auth.log), et dans ce cas, une fonctionnalité similaire doit être activée en définissant un paramètre spécial dans le fichier de paramètres, qui varie d'une distribution à l'autre (SULOG_FILE dans /etc/login.defs sur Ubuntu Linux, /etc/login.conf et /etc/pam.d/su sur FreeBSD, etc.)
dans le cas de su, l'administrateur système ne peut pas restreindre les commandes exécutées par les utilisateurs, mais dans sudo il peut
si l'utilisateur doit être privé des droits d'administration, dans le cas de su, après l'avoir retiré du groupe wheel, il doit oublier le mot de passe root si sudo est utilisé, il suffit de le supprimer du groupe correspondant (par exemple, wheel ou admin) et/ou le fichier sudoers, s'il a été personnalisé davantage.

Q : Je suis le seul utilisateur de mon système et je suis habitué à su, pourquoi ai-je besoin de sudo ?
R : Je vais répondre à la question par une question : s’il existe un sudo correct, pourquoi utiliser le su obsolète ?

par défaut, sudo enregistre toutes les activités des utilisateurs dans le canal syslog authpriv (en règle générale, le résultat est placé dans le fichier /var/log/auth.log), et dans ce cas, une fonctionnalité similaire doit être activée en définissant un paramètre spécial dans le fichier de paramètres, qui varie d'une distribution à l'autre (SULOG_FILE dans /etc/login.defs sur Ubuntu Linux, /etc/login.conf et /etc/pam.d/su sur FreeBSD, etc.)
dans le cas de su, l'administrateur système ne peut pas restreindre les commandes exécutées par les utilisateurs, mais dans sudo il peut
si l'utilisateur doit être privé des droits d'administration, dans le cas de su, après l'avoir retiré du groupe wheel, il doit oublier le mot de passe root si sudo est utilisé, il suffit de le supprimer du groupe correspondant (par exemple, wheel ou admin) et/ou le fichier sudoers, s'il a été personnalisé davantage.

Parfois, il vous suffit d'exécuter une commande d'un autre utilisateur. Et il existe plusieurs manières d’y parvenir. J'en parlerai dans mon article « Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux ».

Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 1

Et ainsi, vous pouvez utiliser l'utilitaire SUDO. Regardons un exemple :

$ sudo -H -u Votre_autre_utilisateur -c "ping site"

Explications :

-H YOUR_HOME : définit HOME (variable d'environnement pour le domicile d'un utilisateur spécifique) et est par défaut root.
-u YOUR_USER : Spécifiez l'utilisateur à partir duquel la commande sera exécutée.
-c YOUR_COMMAND : sert d'option pour saisir une commande.

Quelque chose comme ça.

Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 2

Vous pouvez utiliser l'utilitaire SU. Et maintenant je vais donner quelques exemples.

Connectez-vous en tant qu'utilisateur root

Pour obtenir le root, exécutez :

$su -racine

Exécutez la commande en tant qu'utilisateur root

Voici un exemple de commande :

# su - root -c "VOTRE_COMMAND_HERE"

Su - -c "VOTRE_COMMAND_HERE arg1"

Exécuter une commande d'un autre utilisateur en utilisant su

Voici donc un exemple :

# su -c "/opt/solr/bin/solr create -c test_solr_core -n solrconfig.xml" -s /bin/sh solr Création d'un nouveau noyau "test_solr_core"

Regardons un autre exemple :

$ su autre_utilisateur -c "ping du site"

$su -VOTRE_USER -c "VOTRE_COMMAND_ICI"

— — Simulera la connexion de l'utilisateur spécifié.
-c - Utilisé pour spécifier la commande à exécuter (pour l'utilisateur spécifié).

Quelque chose comme ça.

Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 3

Et ainsi, vous pouvez utiliser l'utilitaire runuser. La commande runuser démarre un shell avec des ID d'utilisateur et de groupe de remplacement. Cette commande n'est utile que lorsque vous êtes connecté en tant que root. La syntaxe est la suivante :

# runuser -l VOTRE_USER -c "VOTRE_COMMAND_HERE"

A titre d'exemple, je vais montrer la ligne suivante :

# runuser -l nginx -c "service nginx start"

PS : La commande runuser ne nécessite pas de mot de passe et ne doit être exécutée que par l'utilisateur root.

Options principales :

-l : crée un shell de connexion en utilisant le fichier PAM runuser-l au lieu de celui par défaut.
-g : pointe vers le groupe principal.
-G : Indique un groupe supplémentaire.
-c : En fait, il est utilisé pour spécifier une commande.
–session-command=COMMAND : passez une seule commande au shell avec l'option « -c » et ne crée pas de nouvelle session.
-m : ne réinitialise pas les variables d'environnement (ENV).

Ça y est, le sujet "Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux" est terminé.

Tout sur la technologie mobile

III.Paramètres sudo avancés.

Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 1

Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 2

Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 3

ARTICLES CONNEXES