GNU/Linux >> Tutoriales Linux >  >> Linux

"error al construir el proxy..." ¿Al intentar iniciar Gnome-terminal como root?

openSUSE Leap 42.2
Gnome Terminal 3.20.2

Tengo una ventana de terminal abierta. Si escribo el siguiente comando:

gnome-terminal

como usuario no root, lanza con éxito una nueva terminal.

Sin embargo, si ejecuto el comando como root, recibo el siguiente mensaje de error:

Error al construir el proxy para
org.gnome.Terminal:/org/gnome/Terminal/Factory0:La conexión está
cerrada

Si trato de iniciar la terminal con dbus-launch gnome-terminal entonces funciona.

¿Qué impide que gnome-terminal ¿Comando que inicia la terminal como root? Y es dbus-launch una solución alternativa aceptable o es probable que cause problemas imprevistos (realmente no entiendo lo que está haciendo)?

Respuesta aceptada:

Recuerde cómo las aplicaciones de Windows funcionaban principalmente en Win16 días antes de que Win32 apareciera y lo eliminara:donde había hInstance y hPrevInstance , intentar ejecutar una segunda instancia de muchas aplicaciones simplemente pasaba las cosas a la primera instancia, y esto dificultó las cosas para las herramientas de secuencias de comandos (como Take Command) porque uno invocaría una aplicación por segunda vez, estaría visiblemente allí en el pantalla como una ventana añadida, pero en lo que respecta al intérprete de comandos, ¿el proceso secundario que acababa de ejecutar salió inmediatamente?

Bueno, GNOME ha recuperado el comportamiento de Win16 para Linux.

GNOME Terminal es ahora una aplicación cliente-servidor. El gnome-terminal El programa es solo un cliente que construye mensajes de Desktop Bus a un servidor, pasando sus opciones de línea de comando, entorno, directorio de trabajo y argumentos, y luego simplemente sale. El servidor es gnome-terminal-server que se registra como org.gnome.Terminal en el bus de escritorio y que es responsable de toda la emulación de terminal real y de mostrar la(s) ventana(s) en la(s) GUI(s).

Un cliente de Desktop Bus como gnome-terminal localiza el corredor de Desktop Bus a través de una variable de entorno, que generalmente apunta a un socket en un directorio por usuario como /run/user/1001 . Alternativamente, la variable de entorno especifica buscar en "el directorio de tiempo de ejecución del usuario actual" y se construye una ruta similar a la mencionada anteriormente a partir de la identificación de usuario efectiva del proceso del cliente. Este directorio, en cualquier caso, es convencionalmente privado para el usuario individual e inaccesible para otros usuarios (sin privilegios).

La hilaridad se produce cuando las personas intentan ejecutar gnome-terminal como otro usuario a través de sudo y cosas por el estilo. Si la variable de entorno apunta a un directorio de tiempo de ejecución con nombre explícito, un cliente sin privilegios no puede conectarse al Bus de escritorio por usuario. Si la variable de entorno apunta al directorio de tiempo de ejecución del "usuario actual", busca el intermediario de Desktop Bus incorrecto, a menudo el de un usuario que no tiene actualmente un agente de Desktop Bus que se ejecuta porque el usuario no inició sesión ni inició los servicios por usuario de esa cuenta de usuario. (Los intermediarios de Bus de escritorio por usuario están a cargo de un administrador de servicios por usuario. El administrador de servicios por usuario se inicia explícitamente o, en el caso de algunos softwares de administración de servicios, mediante algunos ganchos bastante feos en el proceso de autenticación de usuario empleado por los gustos de login , su y programas de servidor SSH).

La razón por la que dbus-launch funcionó para usted como superusuario es que dbus-launch lanzó explícitamente otro agente de Desktop Bus, ejecutándose como superusuario, que gnome-terminal pudo hablar con. Afortunadamente, el sistema también se configuró para solicitar el inicio del gnome-terminal-server servidor cuando el cliente intentó conectarse a él a través del intermediario. (Este no es necesariamente el caso, y hoy en día tal inicio de demanda se considera un mecanismo inferior, ya que termina con muchos procesos de servidor de Desktop Bus que no se ejecutan bajo ningún tipo de administración de servicios. De hecho, no tener el intermediario en sí bajo administración de servicios también se considera inferior. Tampoco se considera generalmente una buena idea para el superusuario para tener este tipo de servicios ejecutándose, ya que muchos de ellos no esperan ejecutarse con privilegios de superusuario porque esperan ejecutarse bajo la protección de cuentas de usuario ordinarias).

Relacionado:¿Cómo hacer que vim funcione correctamente con tmux?

Se produce más hilaridad si, como el interrogador en "¿Cómo puedo iniciar gnome-terminal de forma remota en mi servidor sin cabeza? (no se puede iniciar a través del reenvío X11)” sí, las personas intentan ejecutar gnome-terminal cuando incluso el usuario original no tiene un agente de Bus de escritorio ejecutándose. Esto sucede cuando, por ejemplo, uno ha iniciado sesión a través de SSH pero el proceso de inicio de sesión de SSH no inicia el administrador de servicios por usuario, lo que a su vez significa que el agente de bus de escritorio por usuario no se ejecuta y el gnome-terminal-server No se puede acceder al servidor a través de un bus de escritorio. (Según cómo esté configurado el sistema, el inicio de sesión gráfico aún podría desencadenar el inicio del administrador de servicios por usuario y, por lo tanto, uno podría observar que iniciar sesión gráficamente como el mismo usuario mágicamente hace que las cosas funcionen. Y nuevamente dbus-launch iniciaría explícitamente un intermediario de bus de escritorio no administrado por servicios).

Sin embargo, se produce más hilaridad cuando uno tiene uno de los administradores de servicios que tiene los ganchos para login , su y el servidor SSH. Estos ganchos generalmente implementan la semántica de iniciar la administración de servicios por usuario y todos los servicios por usuario que inicia, en el primer inicio de sesión para ese usuario; y detenerlos a todos en el último cierre de sesión para ese usuario. Si uno tiene muchas sesiones SSH de corta duración y que no se superponen, entonces puede haber una gran cantidad de gastos generales generados inútilmente al iniciar y cerrar todo el sistema de administración de servicios por usuario (y todos sus servicios de inicio automático) en los inicios y finales de cada una de esas sesiones SSH. systemd, uno de esos administradores de servicios, tiene un mecanismo imperfecto de "permanencia" que solo aborda esto a medias. Significa que la administración de servicios por usuario "permanece" después del cierre de sesión final, pero no impide que se inicie la administración de servicios por usuario.

Lecturas adicionales

  • Jonathan de Boyne Pollard (2016). /run/user/jim/dbus . "Diccionario geográfico". Guía de comida . Softwares. jdebp.eu.
  • Jonathan de Boyne Pollard (2016). “servicios de usuario por usuario”. Guía de comida . Softwares. jdebp.eu.
  • Ejecutar verdaderas instancias de múltiples procesos de gnome-terminal
  • Hacer que el servicio systemd del usuario sea persistente
  • https://unix.stackexchange.com/a/323700/5132

Linux
  1. ¿La función de la raíz del grupo de usuarios?

  2. Instalar WordPress en una cuenta de usuario como root

  3. Usuario no raíz predeterminado de Kali

  4. cuando uso CPAN en linux ubuntu, ¿debería ejecutarlo usando sudo / como root o como mi usuario predeterminado?

  5. ¿Ejecutar el comando de shell en jenkins como usuario root?

Cómo agregar un usuario a su escritorio Linux

Linux – Agregar usuario a la lista de Sudoers

Cómo limitar el usuario root en CentOS

¿Cómo habilitar el usuario raíz en Ubuntu Server?

Inicie siempre la Terminal como usuario raíz (sudo) en Ubuntu

Al intentar cambiar el nombre de usuario, la terminal me dice que el usuario está siendo utilizado actualmente por el proceso