Cuando la máquina no tiene cabeza, el usuario ya no tiene privilegios


12

El problema principal es: CUALQUIER sesión de gnomo que no se encuentre encima de una pantalla física / nativa real, o sombrear esa pantalla (es decir, el modo de sombra de NXserver), tiene privilegios defectuosos. ¡Incluso cuando se ejecuta como root!

¿Algún comentario sobre una forma de corregir el comportamiento problemático de las sesiones de VNC / NX no sombra?


Estoy actualizando mi servidor sin cabeza de Ubuntu en casa después de mucho tiempo, y tengo muchos problemas que no recuerdo que existieran en versiones anteriores de Ubuntu.

Algunos detalles:

  • Comencé con ubuntu-11.04-server-amd64.iso y luego instalé ubuntu-desktop encima.
  • uname -a: Linux MiddleEarth 2.6.38-8-server # 42-Ubuntu SMP Lun 11 de abril 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU / Linux
  • El hardware es Intel D920, 2GB Ram, gfx es un nvidia 6600 sin ventilador, 3xGigabit, 1x100mbit, sin monitor, teclado, mouse conectado.

La ronda 1

Mientras realizaba las pruebas / configuración con un monitor conectado , todo era color de rosa, tanto cuando estaba sentado frente a ese monitor como cuando VNC entraba desde mi máquina de escritorio (en vino).

Sin un monitor, aunque surgen problemas:

[Sin resolver / soltado]

El primer problema fue que el vino era terco y no le gustaba cargar antes / durante el GDM. Pero dado que este es un sistema sin cabeza, realmente no lo necesito para comenzar con X de forma predeterminada (es decir, cambiar el nivel de inicio) de todos modos, así que eso es un poco discutible. Sin embargo, recuerdo claramente que esto es muy fácil de hacer en una versión anterior de ubuntu (v9.04, creo). Y funcionó bien; ¿¡pero ya no más!? ... de todos modos dejé caer esa idea por completo.

[Resuelto]

Luego fue Unity / effects messing VNC (Resuelto mediante trampa ).

[No resuelto]

Originalmente cambié a NXserver con la esperanza de que quizás los siguientes problemas sean problemas de tightvnc o vino, pero no tuve tanta suerte. (Nota: leer round2)

Al realizar la conexión remota a través de VNC (o NXserver) mi cuenta de usuario pierde la capacidad de montar / desmontar discos duros.

Captura de pantalla: No se puede montar 750GB_RAID1

Al realizar la conexión remota a través de VNC (o NXserver), mi cuenta de usuario no puede acceder a algunas opciones de configuración privilegiadas,
algunos ejemplos:

  • no puede hacer nada (es decir, 'agregar' un usuario o 'configuración avanzada') en "Sistema -> Administración -> Usuarios y grupos".
  • no se puede usar 'desbloquear' en "Sistema -> Administración -> Pantalla de inicio de sesión".
  • gparted no consigue ninguna información sobre los sistemas de archivos.
  • etc. (varios otros diálogos de administración / configuración tampoco funcionan correctamente)

Solo puedo suponer que esto tiene algo que ver con los privilegios del usuario que no se asignan correctamente cuando un dispositivo de monitor físico real no está conectado.
La razón 'POR QUÉ' esto sucede en ubuntu 11.04, cuando no tiene cabeza, se me escapa; No recuerdo este comportamiento en versiones anteriores de ubuntu.

Tenga en cuenta que el problema de montaje del disco duro no es un problema para los discos duros internos / estáticos (solo los agrego a fstab ya que son estáticos de todos modos). Pero realmente un gran dolor para los medios USB extraíbles.

El resto de los problemas, no he descubierto cómo solucionarlo ...
Sé lo que estás pensando ... ¿iniciar sesión en ssh, sudo su y ejecutar vncserver bajo root por completo?

Captura de pantalla: (como root) gparted no puede encontrar la información de fs

¡Sorpresa sorpresa! la interfaz gráfica de usuario de root también está rota: gparted no puede obtener información, el usuario y los grupos están completamente atenuados (este es un comportamiento diferente al de mi usuario habitual). Por extraño que parezca, el programa de administración de la pantalla de inicio de sesión parece funcionar bien.


La ronda 2

(NOTA: No sé si esto marcó o no una diferencia en el resultado. En algún momento entre la ronda 1 y la ronda 2, apliqué los cambios mencionados en las publicaciones 21 y 24 de este hilo )

Las sesiones regulares de tightvnc / NXServer tienen el mismo comportamiento, PERO ...

[Solución parcial / El problema real sigue ahí]

En la configuración de conexión de NXClient, cuando elijo el modo 'sombra' (la sombra lo adjunta a la pantalla nativa, es decir, el sombreado del escritorio) ...

¡Todo funciona perfecto dentro de esta sesión!

Una cosa que noté es que inmediatamente me pide una contraseña de llavero ... ¿tal vez todo el desastre tiene algo que ver con el sistema de llavero que usa gnome?

Pero, si me conecto con una conexión NX normal (no sombra), o una vnc normal, vuelve a tener los mismos problemas.

PD: Hubo un par de días en el medio cuando escribí round1 y round2 (lo guardaba en un archivo txt localmente). Estaba probando varias sugerencias para ver qué funcionaría, por lo que no estoy seguro de si esa edición del dispositivo xorg.conf VNC o esa configuración de nomodeset hizo la diferencia.

[EDITAR 2011-06-10]

NXServer y GDM

En el momento de escribir esto, había configurado el sistema para iniciar sesión automáticamente, por lo que la conexión en la sombra simplemente funcionó. Cuando más tarde deshabilité eso y reinicié el sistema, NX dio un error, pero con un poco de Google encontré este hilo

Estos son los comentarios y cambios que hice en mi /usr/NX/etc/server.cfg:

EnableAdministratorLogin = "1"
EnableSessionShadowing = "1"
EnableInteractiveSessionShadowing = "1"
EnableSessionShadowingAuthorization = "0"
EnableDesktopSharing = "1"
EnableInteractiveDesktopSharing = "1"
EnableFullDesktopSharing = "1"
EnableAdministratorDesktopSharing = "1"
EnableDesktopSharingAuthorization = "0"
EnableSystemDesktopSharingAuthorization = "0"

(Si fuera una red más pública, es decir, universidad / oficina grande, probablemente usaría una configuración un poco más estricta, pero me conviene).

Después de reiniciar, inicié sesión con nxclient en la configuración de 'sombra' (pantalla nativa) del escritorio y obtuve GDM. :RE

Lamentablemente, el portapapeles no funciona en la sesión 'sombra' (funciona bien en los otros / normales)

[EDITAR 2011-06-11]
Tropecé con Xvfb pero tiene los mismos problemas cuando se usa así:

Xvfb :2 -ac -screen 0 1280x1024x32 -pixdepths 8 24  2>&1 >/dev/null &
export DISPLAY=:2
gnome-session --session=2d-gnome 2>&1 >/dev/null &
x11vnc --display :2 --passwd blahblah

Respuestas:


5

Encontré al culpable.
Probado en una nueva instalación, confirmado que es un error.

Envié un informe de error

En resumen, el problema es: el diálogo de autenticación de Polkit aparecerá en DISPLAY: 0 en lugar de DISPLAY: 1 donde está la sesión VNC / NX.

Una solución alternativa puede ser usar libpam-keyring para autenticarse automáticamente al iniciar sesión.
o ... tacha eso, eso probablemente no lo haría, un cambio para todas las configuraciones del kit de políticas de 'auth_admin' a solo 'sí' probablemente solucionaría el problema, y ​​eso, por supuesto, haría que PolicyKit fuera discutible por completo ... suspiro


1
¿Puedes cambiar tu Xorg.conf para eliminar la pantalla? 0. No veo ninguna razón para que X esté corriendo allí. De esta manera, VNC / NX puede tomar DISPLAY: 0?
user606723

2

Creo que este es el comportamiento correcto de PolicyKit.

La política para Activo , Inactivo y cualquier otro usuario es diferente, por lo que cuando está conectado a través de NX no está Activo (clientes en sesiones activas en consolas locales), ni Inactivo (clientes en sesiones inactivas en consolas locales), pero resulta como Cualquier usuario

Puede ver la política predeterminada para la Acción bajo control de política para los diferentes tipos de usuarios con el comando

pkaction --verbose

Como puede ver, el usuario de tipo Any está limitado en comparación con los usuarios activos.

Para remediarlo, puede modificar la política predeterminada. A continuación, sugiero un script awk para crear un archivo de kit de políticas para colocarlo en la ubicación correcta. Este es el guión:

#!/usr/bin/awk -f

/^[^ ]/ {
  action = substr($0, 1, length($0) - 1)
}
/^ / {
  if ($1 == "description:") {
    $1 = ""
    description = substr($0, 2)
    if (description == "")
      description = action
  } else if ($1 == "implicit") {
    if ($2 == "any:")
      any = $3
    else if ($2 == "inactive:")
      inactive = $3
    else if ($2 == "active:") {
      active = $3
      print ""
      print "[" description "]"
      print "Identity=unix-group:admin"
      print "Action=" action
      print "ResultActive="   active
      print "ResultInactive=" active
      print "ResultAny="      active
    }
  }
}

Supongamos que lo llamas create-policy . Hazlo ejecutable, ejecuta el script con

pkaction --verbose | ./create-policy > local.pkla 

luego mueva el archivo resultante:

sudo mv local.pkla /var/lib/polkit-1/localauthority/50-local.d/

Ahora debería tener el mismo derecho que era un usuario de sesión local.


0

Me encontraba con un problema similar con NX y encontré el siguiente hilo:

¿Por qué obtengo Unity en lugar de Classic cuando uso NX?

Edité mi cliente Windows NX para que el escritorio esté configurado en Unix y Personalizado, luego lo configuré para ejecutar el siguiente comando:

gnome-session --session=classic-gnome

Y seleccionó Nuevo escritorio virtual .
Después de eso estaba listo para irme.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.