Wenn die Maschine kopflos ist, hat der Benutzer keine Privilegien mehr

12

Das Kernproblem ist: ANY Gnome-Sitzung, die nicht auf einem echten physischen / nativen Display sitzt - oder auf einem Shadowing dieser Anzeige (dh Schattenmodus von NXserver) - hat fehlerhafte Privilegien. Selbst wenn es als root ausgeführt wird!

Irgendwelche Kommentare zu einer Möglichkeit, das problematische Verhalten für die VNC / non-shadow NX-Sitzungen zu beheben?

Ich habe meinen Home Ubuntu Headless Server nach einer langen Zeit aktualisiert, und ich habe viele Probleme, von denen ich mich nicht erinnern kann, dass sie in früheren Ubuntu-Versionen existierten.

Einige Details:

  • Ich habe mit ubuntu-11.04-server-amd64.iso begonnen und danach ubuntu-desktop installiert.
  • uname -a: Linux MiddleEarth 2.6.38-8-server # 42-Ubuntu SMP Mo Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU / Linux
  • Die Hardware ist Intel D920, 2 GB RAM, gfx ist einige lüfterlose Nvidia 6600, 3xGigabit, 1x100mbit, kein Monitor, Tastatur, Maus angeschlossen.

Runde 1

Während ich das Testen / Einrichten mit einem Monitor angeschlossen durchführte, war alles wunderbar, sowohl beim Sitzen vor dem Monitor als auch beim VNCing von meinem Desktop-Rechner (in Vino).

Ohne Monitor treten jedoch Probleme auf:

[Nicht aufgelöst / gelöscht]

Das sehr erste Problem war, dass vino stur war und es nicht mochte, vor / während GDM zu laden. Aber da dies ein kopfloses System ist, brauche ich es nicht wirklich, standardmäßig mit X zu beginnen (dh das Init-Level zu ändern), also ist das ein bisschen verwerflich. Ich erinnere mich jedoch deutlich daran, dass es sehr einfach ist, sehr zu sein in einer älteren ubuntu-Version (v9.04 denke ich). Und es hat gut funktioniert; aber nicht mehr!? ... jedenfalls habe ich diese Idee völlig fallen gelassen.

[Gelöst]

Dann war es Unity / effects messing VNC (löste es durch Betrug ).

[Nicht aufgelöst]

Ich bin ursprünglich zu NXserver gewechselt, in der Hoffnung, dass die folgenden Probleme Engpässe oder Vino-Probleme sind, aber kein Glück. (Hinweis: lesen Sie round2)

Beim Remoting über VNC (oder NXserver) verliert mein Benutzerkonto die Fähigkeit, Festplatten zu mounten / unmounten.

Beim Remoting über VNC (oder NXserver) kann mein Benutzerkonto nicht auf einige privilegierte Konfigurationsoptionen zugreifen,
einige Beispiele:

  • kann in "System - & gt; Administration - & gt; Benutzer und Gruppen" nichts tun (dh "einen Benutzer hinzufügen" oder "erweiterte Einstellungen").
  • kann "Entsperren" nicht in "System - & gt; Administration - & gt; Anmeldebildschirm" verwenden.
  • gparted kann keine Informationen über die Dateisysteme erhalten.
  • usw. (Verschiedene andere Admin / Config-Dialoge funktionieren auch nicht richtig)

Ich kann nur vermuten, dass dies etwas damit zu tun hat, dass Benutzerberechtigungen nicht richtig zugewiesen werden, wenn ein tatsächliches physisches Überwachungsgerät nicht angeschlossen ist.
Der Grund warum es in ubuntu 11.04 passiert, wenn es kopflos ist, entgeht mir; Ich erinnere mich nicht an dieses Verhalten in früheren Versionen von Ubuntu.

Beachten Sie, dass das Problem mit der Festplattenmontage für interne / statische Festplatten kein Problem ist (ich füge sie einfach zur fstab hinzu, da sie sowieso statisch sind). Aber wirklich ein großer Schmerz für entfernbare USB-Medien.

Der Rest der Probleme, ich habe nicht herausgefunden, wie man ... repariert Ich weiß, was du denkst ... logge dich in ssh, sudo su ein und führe vncserver unter root komplett aus?

Überraschungsüberraschung! root's gui ist auch defekt: gparted kann keine Informationen erhalten, Benutzer und Gruppen sind vollständig ausgegraut (dies ist ein anderes Verhalten als mein normaler Benutzer). Seltsamerweise scheint das Login-Bildschirm-Administrationsprogramm gut zu funktionieren.

Runde 2

(HINWEIS: Ich weiß nicht, ob das für das Ergebnis eine Rolle gespielt hat oder nicht. Irgendwann zwischen Runde 1 und Runde 2 habe ich die in den Beiträgen # 21 und # 24 erwähnten Änderungen in dieser Thread )

Die regulären tightvnc / NXServer-Sitzungen haben das gleiche Verhalten, ABER ...

[Teillösung / Das eigentliche Problem ist immer noch da]

In den NXClient-Verbindungseinstellungen, wenn ich den "Schatten" -Modus wähle (Schatten verbindet dich mit der nativen Anzeige, dh Desktop-Shadowing) ...

Alles funktioniert perfekt in dieser Sitzung!

Eins ist mir aufgefallen, dass es mich sofort nach einem Schlüsselring-Passwort fragt ... vielleicht hat das ganze Durcheinander etwas mit dem Schlüsselring-System zu tun, das gnome benutzt?

Aber, wenn ich eine Verbindung mit einer normalen (nicht Schatten) NX-Verbindung oder einem normalen VNC herstelle, geht es wieder zu den gleichen Problemen.

P.S. Es gab ein paar Tage dazwischen, als ich Runde 1 und Runde 2 schrieb (ich habe es lokal in einer TXT-Datei gespeichert). Ich habe verschiedene Tests getestet, um zu sehen, was funktionieren würde, weshalb ich nicht sicher bin, ob das Xorg ist.conf VNC device edit oder die Nomodeset-Einstellung hat einen Unterschied gemacht.

[EDIT 2011-06-10]

NXServer und GDM

Zum Zeitpunkt des Schreibens hatte ich das System auf automatische Anmeldung eingestellt, weshalb die Schattenverbindung einfach funktioniert hat. Als ich später das deaktivierte und das System neu startete, gab NX einen Fehler, aber mit ein wenig Googeln fand ich diesen Thread

Dies sind die Kommentarzeichen und Änderungen, die ich an meiner /usr/NX/etc/server.cfg vorgenommen habe:

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

(Wenn es ein öffentliches Netzwerk wäre, dh Universität / großes Büro, würde ich wahrscheinlich ein wenig strengere Einstellungen verwenden, aber diese passen mir gut.)

Nach einem Neustart habe ich mich mit nxclient bei der Desktop-Einstellung "shadow" (native Anzeige) angemeldet und GDM! : D

Leider Zwischenablage funktioniert nicht in der 'Schatten' Sitzung (Es funktioniert auf der anderen / regulären fein)

[EDIT 2011-06-11]
Stolperte über Xvfb , aber es hat die gleichen Probleme, wenn es so verwendet wird:

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
    
DM8 10.06.2011, 02:22
quelle

3 Antworten

5

Ich habe den Schuldigen ausfindig gemacht.
Getestet auf einer neuen Installation, bestätigt, dass es ein Fehler ist.

Ich habe einen Fehlerbericht

eingereicht

Kurz gesagt, das Problem ist: Der Polkit-Authentifizierungsdialog wird auf DISPLAY angezeigt: 0 statt DISPLAY: 1 wo die VNC / NX-Sitzung ist.

Eine Umgehungslösung kann sein, um libpam-keyring zu verwenden, um sich bei der Anmeldung automatisch zu authentifizieren.
oder ... scratchen, das würde es wahrscheinlich nicht tun, eine Änderung für alle Richtlinieneinstellungen von "auth_admin" zu "ja" würde das Problem wahrscheinlich lösen, und das würde natürlich policyKit komplett machen ... seufzen

    
DM8 16.06.2011, 01:52
quelle
2

Ich denke, das ist das richtige PolicyKit-Verhalten.

Die Richtlinien für Aktiv , Inaktiv und Alle anderen Benutzer sind unterschiedlich. Wenn Sie also über NX verbunden sind, sind Sie nicht Aktiv (Clients in aktiven Sitzungen auf lokalen Konsolen), oder Inaktiv (Clients in inaktiven Sitzungen auf lokalen Konsolen), aber Sie erhalten den Any Benutzer.

Sie können die Standardrichtlinie für die Aktion unter Richtlinienkontrolle für die verschiedenen Benutzertypen mit dem Befehl

sehen
pkaction --verbose

Wie Sie sehen können, ist der Benutzer vom Typ Beliebig im Vergleich mit aktiven Benutzern eingeschränkt.

Um dies zu beheben, können Sie die Standardrichtlinie ändern. Im Folgenden schlagen Sie ein awk-Skript vor, um eine Policy-Kit-Datei zu erstellen, die an der richtigen Stelle eingefügt wird. Dies ist das Skript:

#!/usr/bin/awk -f

/^[^ ]/ {
  action = substr(
pkaction --verbose | ./create-policy > local.pkla 
, 1, length(
sudo mv local.pkla /var/lib/polkit-1/localauthority/50-local.d/
) - 1) } /^ / { if ( == "description:") { = "" description = substr(%pre%, 2) if (description == "") description = action } else if ( == "implicit") { if ( == "any:") any = else if ( == "inactive:") inactive = else if ( == "active:") { active = print "" print "[" description "]" print "Identity=unix-group:admin" print "Action=" action print "ResultActive=" active print "ResultInactive=" active print "ResultAny=" active } } }

Angenommen, Sie nennen es create-policy . Mach es ausführbar, führe das Skript mit

aus %pre%

dann verschieben Sie die resultierende Datei:

%pre%

Sie sollten nun das gleiche Recht wie ein lokaler Sitzungsbenutzer haben.

    
enzotib 21.07.2011 22:29
quelle
0

Ich stieß auf ein ähnliches Problem mit NX und fand den folgenden Thread:

Warum bekomme ich Unity statt? Classic bei Verwendung von NX?

Ich habe meinen Windows NX-Client bearbeitet, sodass der Desktop auf Unix & amp; Benutzerdefiniert, dann legen Sie den folgenden Befehl fest:

gnome-session --session=classic-gnome

Und ausgewählt Neuer virtueller Desktop .
Danach war ich gut zu gehen.

    
David B 21.07.2011 20:37
quelle

Tags und Links