Pourquoi les utilisateurs ne devraient-ils jamais utiliser sudo pour lancer des applications graphiques?

114

J'ai lu la documentation de la communauté "RootSudo" et cette ligne m'intéresse:

Vous ne devriez jamais utiliser sudo normal pour lancer des applications graphiques en tant que racine.

Pourquoi? Quelle est la différence? Veuillez fournir une explication simple car je ne suis qu'un utilisateur de bureau normal.

sudo gui gksu Nur
la source
3
Connexes: quelle est la différence entre “gksudo nautilus” et “sudo nautilus”?
Eliah Kagan
En fait, j'ai récemment eu du mal à installer MATLAB dans / usr / local. Cela nécessitait des privilèges root pour écrire dans / usr / local, mais l’exécution du programme d’installation à l’aide de gksu empêchait l’exécution du programme installé en tant que non-root. L'exécution du programme d'installation à l'aide de sudo a parfaitement fonctionné.
Bavoir perdu

Réponses:

129

Les applications graphiques stockent souvent des paramètres et d'autres données spécifiques à l'utilisateur dans des fichiers de configuration écrits dans le dossier personnel de l'utilisateur . Le principal mécanisme utilisé par les applications pour déterminer ce qu’elles doivent utiliser comme dossier de base de l’utilisateur est la HOME variable d’environnement . (Vous pouvez l'inspecter vous-même avec echo $HOME).

Supposons que vous exécutiez gedit(un éditeur de texte graphique) en tant que root. Si vous exécutez sudo gedit, HOMEcontinuera à pointer vers votre répertoire de base, même si le programme est exécuté en tant queroot . Par conséquent, geditécrira les fichiers de configuration commeroot dans votre répertoire personnel. Cela va parfois entraîner dans les fichiers de configuration étant propriété parroot et donc inaccessibles pour vous (lorsque vous exécutez le programme plus tard comme toi - même et non pas root). Cela se produit principalement lorsque l'application doit créer un nouveau fichier de configuration. Les fichiers nouvellement créés, par défaut, appartiennent à l'utilisateur qui les crée (c'est-à-dire root, ce n'est pas vous).

C'est la raison principale pour laquelle vous devriez exécuter des applications graphiques avec une interface graphique sudoplutôt qu'avec straight sudo. Dans Ubuntu et la plupart de ses dérivés (y compris Xubuntu et Lubuntu), l’interface graphique standard est gksu/gksudo . À Kubuntu c'est kdesudo. (Cela dépend de l' environnement de bureau utilisé.)

Si vous souhaitez utiliser sudodirectement pour exécuter une application graphique comme gedit, vous pouvez exécuter:

sudo -H gedit

L' -Hindicateur fait en sudosorte HOMEde pointer vers rootle dossier de départ de (qui est /root).

Cela ne gèrera toujours pas automatiquement la propriété de celui-ci .Xauthorityen le copiant dans un dossier temporaire (ceci est l’autre chose que les interfaces graphiques sudogèrent pour vous). Mais dans l'événement peu fréquent qui .Xauthorityest inaccessible, vous obtiendrez une erreur et vous pourrez alors résoudre le problème en le supprimant ( sudo rm ~/.Xauthority), car il est automatiquement régénéré. Par conséquent, protéger .Xauthorityla propriété et les autorisations est moins important que protéger la propriété et les autorisations des fichiers de configuration.

Contrairement à une rootdétenue .Xauthority, lorsque les fichiers de configuration sont la propriété que root, ce n'est pas toujours aussi évident que le problème est (parce que les programmes graphiques fonctionneront souvent, mais pas très bien, et la sortie des erreurs utiles à la console). Et il est parfois plus fastidieux de résoudre ce problème, en particulier si vous souhaitez qu'un ou plusieurs fichiers de votre répertoire personnel appartiennent à quelqu'un d'autre que vous (car vous ne pouvez pas le résoudre simplement en récursant chowntous vos fichiers). retour à vous-même).

Par conséquent, sudo(du moins sans -H) ne doit pas être utilisé pour exécuter une application graphique, sauf si vous êtes parfaitement familiarisé avec le fonctionnement interne de l' application et si vous savez avec certitude qu'il ne tente jamais d'écrire des fichiers de configuration.

Eliah Kagan
la source
Puis-je redevenir propriétaire de tous les fichiers de configuration (ou de tout fichier) de mon répertoire personnel, si ces fichiers appartiennent à root?
Nur
@Nur En supposant qu'aucun fichier de votre répertoire personnel ne soit la propriété d'un autre utilisateur ou que vous souhaitiez appartenir à un autre groupe (pour le partage) , vous pouvez exécuter: sudo chmod -R $USER:$USER ~Malheureusement, ces critères ne s'appliquent pas toujours. Si vous avez des fichiers pour lesquels vous devez conserver le propriétaire du groupe, vous pouvez les exécuter sudo chmod -R $USER ~. Ceci est généralement suffisant. (Si certains de vos fichiers doivent appartenir à un autre utilisateur de votre répertoire personnel, cela posera un problème.)
Eliah Kagan
1
@EliahKagan chmodfait-il réellement? J'ai toujours pensé que c'était ça chownqui l'avait fait. chmodne l'a jamais fait pour moi.
Wyatt8740
2
@ Wyatt8740 J'aurais certainement dû écrire chownau lieu de chmoddans mes commentaires ci-dessus. Désolé pour cela - et merci de l'avoir signalé!
Eliah Kagan
2
En @TheQuark sudo -H echo $HOME, votre shell - en cours d' exécution que vous, et non pas en tant que root - effectue l' expansion des paramètres sur $HOME, obtenir le chemin de votre répertoire personnel, puis passe à ce sudoqui passe à son tour la valeur déjà étendue à echo, qu'elle imprime. sudo -H printenv HOME, sudo -H bash -c 'echo $HOME'et sudo -H sh -c 'echo $HOME'tous imprimés /root. Ceci est conceptuellement similaire - bien que par un mécanisme différent - à la façon dont l’ x=a echo "$x"impression n’est pas effectuée a(à moins qu’elle ait xdéjà eu la valeur a).
Eliah Kagan
25

Tout simplement:

Cela évite que les fichiers de votre répertoire personnel ne deviennent la propriété de root.

Lisez le ici . Aussi, éventuellement, une copie de Quelle est la différence entre "gksudo nautilus" et "sudo nautilus"?

Carnendil
la source
gksudo n'est plus inclus dans les installations Ubuntu et Debian. Voir itsfoss.com/gksu-replacement-ubuntu pour plus de détails. askubuntu.com/a/1047413/197910 est maintenant la solution supérieure.
K7AAY le
5

Une alternative à gksu nautiluset gksu geditconsiste à utiliser des nautilus-adminadd-on. Il vous permet de parcourir des fichiers et des répertoires avec Nautilus , puis de les ouvrir en tant que root (administrateur).

L'installation est simple:

sudo apt install nautilus-admin

Maintenant, lorsque vous êtes dans Nautilus, vous aurez une option supplémentaire pour Éditer en tant qu'administrateur:

Nautilus admin.gif

gedit en tant que root ne permet pas les préférences

Lorsque vous vous lancez en gedittant que root, vous ne pouvez pas utiliser les préférences que vous avez définies en tant qu'utilisateur standard pour les tabulations, les convertir en espaces, le nom de la police, la taille de la police, le retour à la ligne, etc.

Pour résoudre ce problème, j'ai écrit le script sgeditpour hériter des préférences de l'utilisateur et les appliquer à la racine: Comment synchroniser mon gedit avec les préférences de mon utilisateur?

  • Appeler en utilisant sgedit filename1 filename2 ...
  • Obtient les paramètres gedit de l'utilisateur pour les tabulations, les polices, le retour à la ligne, etc.
  • S'élève pour sudo -Hpréserver la propriété des fichiers tout en obtenant les pouvoirs de la racine.
  • Demande le mot de passe si le dernier sudoa expiré.
  • Obtient les paramètres gedit de sudo
  • Compare les différences entre les paramètres utilisateur et sudo gedit
  • Exécute les paramètres définis uniquement sur les différences (réduit le nombre de commandes à une douzaine ou moins. La prochaine fois, il exécutera peut-être une ou deux modifications, mais souvent aucune modification.
  • Appels gediten tâche de fond tels que l'invite du terminal réapparaisse immédiatement.
WinEunuuchs2Unix
la source