openSUSE Leap 42.2
Terminal Gnome 3.20.2
J'ai une fenêtre de terminal ouverte. Si je tape la commande suivante :
gnome-terminal
en tant qu'utilisateur non root, il lance avec succès un nouveau terminal.
Cependant, si j'exécute la commande en tant que root, j'obtiens le message d'erreur suivant :
Erreur lors de la construction du proxy pour
org.gnome.Terminal :/org/gnome/Terminal/Factory0 :la connexion est
fermée
Si j'essaie de lancer le terminal avec dbus-launch gnome-terminal alors ça marche.
Qu'est-ce qui empêche le gnome-terminal commande lançant le terminal en tant que root ? Et est dbus-launch une solution de contournement acceptable ou susceptible de causer des problèmes imprévus (je ne comprends pas vraiment ce qu'il fait) ?
Réponse acceptée :
Rappelez-vous comment les applications Windows fonctionnaient principalement à l'époque de Win16 avant que Win32 n'arrive et ne s'en débarrasse :où il y avait hInstance et hPrevInstance , tenter d'exécuter une deuxième instance de nombreuses applications a simplement remis les choses à la première instance, et cela a rendu les choses difficiles pour les outils de script de commande (comme Take Command) car on invoquait une application une deuxième fois, elle serait visiblement là sur le écran en tant que fenêtre ajoutée, mais en ce qui concerne l'interpréteur de commandes, le processus enfant qu'il venait d'exécuter s'est immédiatement arrêté ?
Eh bien, GNOME a ramené le comportement Win16 pour Linux.
GNOME Terminal est désormais une application client-serveur. Le gnome-terminal Le programme est juste un client qui construit des messages Desktop Bus vers un serveur, en transmettant ses options de ligne de commande, son environnement, son répertoire de travail et ses arguments, puis en quittant simplement. Le serveur est gnome-terminal-server qui s'enregistre en tant que org.gnome.Terminal sur le bus de bureau et qui est responsable de toute l'émulation de terminal réelle et de l'affichage de la ou des fenêtres sur la ou les interfaces graphiques.
Un client Desktop Bus comme gnome-terminal localise le courtier Desktop Bus via une variable d'environnement, qui pointe généralement vers socket dans un répertoire par utilisateur tel que /run/user/1001 . Alternativement, la variable d'environnement spécifie de rechercher dans "le répertoire d'exécution de l'utilisateur actuel" et un chemin similaire à celui mentionné ci-dessus est construit à partir de l'ID utilisateur effectif du processus client. Ce répertoire dans les deux cas est classiquement privé pour l'utilisateur individuel et inaccessible aux autres utilisateurs (non privilégiés).
L'hilarité s'ensuit lorsque les gens tentent d'exécuter gnome-terminal en tant qu'autre utilisateur via sudo et ainsi de suite. Si la variable d'environnement pointe vers un répertoire d'exécution explicitement nommé, un client non privilégié ne peut pas se connecter au bus de bureau par utilisateur. Si la variable d'environnement pointe vers le répertoire d'exécution de "l'utilisateur actuel", elle recherche le mauvais courtier Desktop Bus, souvent celui d'un utilisateur qui n'en a pas actuellement un courtier Desktop Bus en cours d'exécution parce que l'utilisateur ne s'est pas connecté et n'a pas démarré les services par utilisateur de ce compte d'utilisateur. (Les courtiers de bus de bureau par utilisateur sont gérés par un gestionnaire de services par utilisateur. Le gestionnaire de services par utilisateur est lancé explicitement ou, dans le cas de certains logiciels de gestion de services, par des crochets plutôt laids dans le processus d'authentification des utilisateurs utilisé par comme le login , su , et programmes serveur SSH.)
La raison pour laquelle dbus-launch travaillé pour vous en tant que superutilisateur est que dbus-launch lancé explicitement un autre courtier Desktop Bus, exécuté en tant que superutilisateur, qui gnome-terminal a pu parler. Heureusement, le système a également été configuré pour démarrer à la demande le gnome-terminal-server serveur lorsque le client a tenté de s'y connecter via le courtier. (Ce n'est pas nécessairement le cas, et de nos jours, un tel démarrage à la demande est considéré comme un mécanisme inférieur car il se termine par de nombreux processus de serveur Desktop Bus qui ne s'exécutent sous aucun type de gestion de service. En effet, ne pas avoir le courtier lui-même sous la gestion des services est également considéré comme inférieur. Ce n'est généralement pas non plus considéré comme une bonne idée pour le superutilisateur compte pour avoir ces types de services en cours d'exécution, car beaucoup d'entre eux ne s'attendent pas à être exécutés avec des privilèges de superutilisateur car ils s'attendent à être exécutés sous les égides de comptes d'utilisateurs ordinaires.)
Une autre hilarité s'ensuit si, comme l'interrogeait « Comment puis-je lancer gnome-terminal à distance sur mon serveur sans tête ? » (ne parvient pas à se lancer via le transfert X11)", les utilisateurs tentent d'exécuter gnome-terminal lorsque même l'utilisateur d'origine n'a pas de courtier Desktop Bus en cours d'exécution. Cela se produit lorsque, par exemple, une personne s'est connectée via SSH mais que le processus de connexion SSH ne démarre pas le gestionnaire de services par utilisateur, ce qui signifie que le courtier Desktop Bus par utilisateur n'est pas exécuté et que le gnome-terminal-server serveur ne peut pas être atteint via un bus de bureau. (Selon la configuration du système, la connexion graphique peut toujours déclencher le démarrage du gestionnaire de services par utilisateur, et on peut donc observer que la connexion graphique en tant que même utilisateur fait fonctionner les choses comme par magie. Et encore dbus-launch démarrerait explicitement un courtier de bus de bureau non géré par le service.)
Encore plus d'hilarité s'ensuit lorsque l'un des gestionnaires de service a les crochets dans login , su , et le serveur SSH. Ces crochets implémentent généralement la sémantique de démarrage de la gestion des services par utilisateur et de tous les services par utilisateur qu'elle démarre, lors de la première connexion pour cet utilisateur ; et les arrêter tous à la dernière déconnexion pour cet utilisateur. Si l'on a beaucoup de sessions SSH de courte durée et sans chevauchement, alors il peut y avoir beaucoup de temps système généré inutilement lors du démarrage et de l'arrêt de l'ensemble du système de gestion des services par utilisateur (et de tous ses services de démarrage automatique) à le début et la fin de chacune de ces sessions SSH. systemd, l'un de ces gestionnaires de services, a un mécanisme imparfait de « persistance » qui ne résout ce problème qu'à moitié. Cela signifie que la gestion des services par utilisateur "s'attarde" après la déconnexion finale, mais cela n'empêche pas du tout le démarrage de la gestion des services par utilisateur.
Autres lectures
- Jonathan de Boyne Pollard (2016).
/run/user/jim/dbus. "Gazetier". Guide bouffe . Logiciels. jdebp.eu. - Jonathan de Boyne Pollard (2016). "services utilisateur par utilisateur". Guide bouffe . Logiciels. jdebp.eu.
- Exécuter de véritables instances de processus multiples de gnome-terminal
- Rendre le service utilisateur systemd persistant
- https://unix.stackexchange.com/a/323700/5132