Question Pourquoi les utilisateurs ne devraient-ils jamais utiliser sudo normal pour démarrer des applications graphiques?


j'ai lu la documentation "RootSudo" de la communauté et suis intéressé par cette ligne:

Vous devriez jamais utilisez sudo normal pour lancer les 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.


93
2018-03-19 16:35


origine


En relation: Quelle est la différence entre “gksudo nautilus” et “sudo nautilus”? - Eliah Kagan
En fait, j'ai récemment eu du mal à installer MATLAB sur / usr / local. Cela exigeait des privilèges root pour écrire dans / usr / local, mais l'exécution du programme d'installation à l'aide de gksu rendait impossible l'exécution du programme installé en tant que non-root. En exécutant le programme d’installation à l’aide de sudo, tout fonctionnait bien. - Bib-lost


Réponses:


Les applications graphiques stockent souvent des paramètres et d'autres données spécifiques à l'utilisateur dans des fichiers de configuration écrits à l'intérieur de l'utilisateur. dossier personnel. Les principales applications du mécanisme permettent de déterminer ce qu’elles doivent utiliser en tant que dossier personnel de l’utilisateur. HOME  variable d'environnement. (Vous pouvez l'inspecter vous-même avec echo $HOME).

Supposons que vous courez gedit (un éditeur de texte graphique) root. Si tu cours sudo gedit, HOME continuera à pointer vers votre répertoire de base, même si le programme est en cours d'exécution comme root. Par conséquent, gedit va écrire des fichiers de configuration comme root dans votre répertoire personnel. Ce aboutira parfois dans les fichiers de configuration étant possédé par root Et ainsi inaccessible à vous (Lorsque vous exécuterez le programme plus tard comme vous-même et non comme 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 (qui, dans ce cas, est root, pas toi).

C'est la raison principale pour laquelle vous devez exécuter des applications graphiques avec un graphique sudo frontend plutô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. Dans Kubuntu c'est kdesudo. (Cela dépend de la environnement de bureau utilisé.)

Si vous vouloir utiliser sudo directement pour exécuter une application graphique comme gedit, tu peux courir:

sudo -H gedit

le -H le drapeau fait sudo ensemble HOME pointer vers rootdossier personnel de /root).

Cela ne gère toujours pas automatiquement la propriété de .Xauthority en le copiant dans un dossier temporaire (c’est l’autre chose que sudo les frontends prennent soin de vous). Mais dans le cas peu fréquent que .Xauthority est inaccessible, vous aurez une erreur en disant que c'est, et puis vous pouvez résoudre le problème en le supprimant (sudo rm ~/.Xauthority), car il est régénéré automatiquement. Ainsi, en protégeant .XauthorityLa propriété et les autorisations sont moins importantes que la protection de la propriété et des autorisations des fichiers de configuration.

Contrairement à un rootpropriétaire .Xauthority, lorsque les fichiers de configuration deviennent la propriété de rootLe problème n'est pas toujours évident (car les programmes graphiques sont souvent exécutés, mais ne fonctionnent pas très bien et génèrent des erreurs utiles sur la console). Et c'est parfois un problème plus difficile à résoudre, en particulier si vous êtes dans une situation où vous souhaitez qu'un ou plusieurs fichiers de votre répertoire personnel appartiennent à une personne autre que vous(car alors vous ne pouvez pas le réparer simplement en récursif chowntous vos fichiers à vous).

Donc, sudo (au moins sans -H) ne doit pas être utilisé pour exécuter une application graphique sauf si vous êtes très familier avec le fonctionnement interne de l'application et vous êtes sûr de ne jamais essayer d'écrire des fichiers de configuration.


104
2018-03-19 16:49



Puis-je redevenir propriétaire de tous les fichiers de configuration (ou de tous les fichiers) de mon répertoire personnel, si ces fichiers appartiennent à root? - Nur
@Nur En supposant qu'il y ait non des fichiers dans votre répertoire personnel que vous vouloir être la propriété de tout autre utilisateur ou que vous voulez avoir une autre appartenance à un groupe (pour le partage), tu peux courir: sudo chmod -R $USER:$USER ~ Malheureusement, ces critères ne s'appliquent pas toujours. Si vous avez des fichiers où vous devez conserver le propriétaire du groupe, vous pouvez exécuter sudo chmod -R $USER ~. C'est généralement suffisant. (Si vous avez des fichiers qui doivent appartenir à un autre utilisateur dans votre répertoire personnel, cela posera même un problème.) - Eliah Kagan
Je veux juste que ces fichiers m'appartiennent, merci. - Nur
@EliahKagan fait chmod vraiment le faire? J'ai toujours pensé que c'était chown ça l'a fait. chmod Je ne l'ai jamais fait pour moi. - Wyatt8740
@ Wyatt8740 Je devrais absolument avoir écrit chown au lieu de chmod dans mes commentaires ci-dessus. Désolé pour cela - et merci de le signaler! - Eliah Kagan


Tout simplement:

Cela empêche les fichiers de votre répertoire personnel de devenir la propriété de root.

Lis le ici. Aussi, éventuellement un duplicata de Quelle est la difference entre "gksudo nautilus" et "sudo nautilus"?


23
2018-03-19 16:40





Une alternative à gksu nautilus et gksu gedit est d'utiliser nautilus-admin Ajouter. Il vous permet de parcourir des fichiers et des répertoires avec Nautile puis ouvrez-les en tant que root (Administrateur).

L'installation est simple:

sudo apt install nautilus-admin

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

nautilus admin.gif


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

Quand tu cours gedit En tant que root, vous ne pouvez pas utiliser les préférences que vous avez configurées en tant qu'utilisateur régulier pour les tabulations, convertir les onglets 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 sgedit pour hériter des préférences de l'utilisateur et les appliquer à la racine: Comment synchroniser mon root gedit avec les préférences de mon utilisateur gedit?

  • Appel 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 à sudo -H préserver la propriété du fichier tout en obtenant des pouvoirs root.
  • Demande le mot de passe si dernier sudo a expiré.
  • Obtient les paramètres de gedit de sudo
  • Compare les différences entre les paramètres utilisateur et sudo gedit
  • Exécute uniquement les gsettings sur les différences (réduit les commandes de 174 à une douzaine ou moins. La prochaine fois, il exécutera peut-être seulement une ou deux modifications, mais souvent aucune modification.
  • Appels gedit comme tâche d'arrière-plan telle que l'invite du terminal réapparaisse immédiatement.

0
2018-06-17 18:15