Quando la macchina non funziona, l'utente non ha più privilegi

12

Il problema principale è: QUALSIASI sessione di gnome che non si trova su un vero display fisico / nativo - o shadowing che visualizza (cioè la modalità shadow di NXserver) - ha dei privilegi errati. Anche quando esegui come root!

Qualche commento su un modo per correggere il comportamento problematico per le sessioni NX VNC / non shadow?

Sto aggiornando il mio server headless Ubuntu dopo un lungo periodo e ho molti problemi che non ricordo esistessero nelle precedenti versioni di Ubuntu.

Alcuni dettagli:

  • Ho iniziato con ubuntu-11.04-server-amd64.iso e poi ho installato ubuntu-desktop sopra.
  • uname -a: Linux MiddleEarth 2.6.38-8-server # 42-Ubuntu SMP Lun 11 apr 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU / Linux
  • L'hardware è Intel D920, 2GB Ram, gfx è un fan nvidia 6600, 3xGigabit, 1x100mbit, nessun monitor, tastiera, mouse collegato.

Round 1

Mentre eseguivo il testing / setup con un monitor attached , tutto era peachy, sia quando si trovava di fronte a quel monitor sia quando si entrava in VNC dalla mia macchina desktop (in vino).

Senza un monitor se sorgono problemi:

[Unsolved / Dropped]

Il primo primo problema è stato vino essere testardi e non graditi a caricare prima / durante GDM. Ma dal momento che questo è un sistema senza testa, non ho davvero bisogno di iniziare con X di default (cioè cambiare il livello di init) comunque, quindi è un po 'discutibile. Tuttavia, ricordo distintamente che questo è molto facile fare in una vecchia versione di Ubuntu (v9.04 penso). E ha funzionato bene; ma non più!? ... comunque ho lasciato cadere quell'idea.

[Risolto]

Poi è stato Unity / effects messing VNC (Risolto esso imbrogli ).

[Unsolved]

Originariamente sono passato a NXserver sperando che forse i seguenti problemi sono problemi tightvnc o vino, ma non ho avuto tanta fortuna. (Nota: leggi round2)

Quando si esegue il remoting tramite VNC (o NXserver) il mio account utente perde la capacità di montare / smontare gli HDD.

Quando si esegue il remoting tramite VNC (o NXserver) il mio account utente non può accedere ad alcune opzioni di configurazione privilegiate,
alcuni esempi:

  • non può fare nulla (ad esempio 'aggiungere' un utente o 'impostazioni avanzate') in "Sistema - & gt; Amministrazione - & gt; Utenti e gruppi".
  • non può utilizzare "sblocco" in "Sistema - & gt; Amministrazione - & gt; Schermata di accesso".
  • gparted non riesce a ottenere alcuna informazione sui filesystem.
  • ecc. (vari altri dialoghi di amministrazione / configurazione non funzionano correttamente)

Posso solo immaginare che questo abbia qualcosa a che fare con i privilegi dell'utente che non vengono assegnati correttamente quando un dispositivo di monitoraggio fisico non è connesso.
La ragione per cui "questo succede in Ubuntu 11.04, quando è senza testa, mi sfugge; Non ricordo questo comportamento nelle versioni precedenti di Ubuntu.

Si noti che il problema di montaggio dell'HDD è un problema per gli hdd interni / statici (li aggiungo solo a fstab poiché sono statici in ogni caso). Ma davvero un grande problema per i supporti USB rimovibili.

Il resto dei problemi, non ho capito come risolvere ...
So cosa stai pensando ... accedi a ssh, sudo su ed esegui vncserver sotto root interamente?

Sorpresa sorpresa! anche il root di gui è rotto: gparted non riesce a ottenere informazioni, i gruppi di utenti sono completamente disattivati ​​(questo è un comportamento diverso da quello del mio utente abituale). Stranamente, la schermata di login proggy sembra funzionare bene.

Round 2

(NOTA: non so se questo ha fatto o non ha fatto la differenza per il risultato. Ad un certo punto tra il round 1 e il round 2, ho applicato le modifiche menzionate nei post # 21 e # 24 in this thread )

Le normali sessioni tightvnc / NXServer hanno lo stesso comportamento, MA ...

[Soluzione parziale / Il problema attuale è ancora lì]

Nelle impostazioni della connessione NXClient, quando scelgo la modalità 'ombra' (l'ombreggiatura ti attacca al display nativo, ad esempio il desktop shadowing) ...

Tutto funziona alla perfezione in questa sessione!

Una cosa che ho notato è che mi chiede immediatamente una password per il keyring ... forse l'intero casino ha qualcosa a che fare con il sistema di keyring usato da gnome?

Ma, se mi collego con una normale connessione NX (non shadow), o con un normale vnc, si torna ad avere gli stessi problemi.

P.S. Ci sono stati un paio di giorni in conflitto quando ho scritto round1 e round2 (lo stavo tenendo in un file txt localmente). Stavo testando varie ipotesi per vedere cosa avrebbe funzionato, ed è per questo che non so per certo se quel xorg.conf Modifica del dispositivo VNC o che l'impostazione del nomodeset ha fatto la differenza.

[EDIT 2011-06-10]

NXServer e GDM

Al momento della scrittura avevo impostato il sistema per l'accesso automatico, motivo per cui la connessione shadow funzionava semplicemente. Quando in seguito l'ho disabilitato e ho riavviato il sistema, NX ha dato un errore, ma con un po 'di ricerca su Google ho trovato questo thread

Questi sono i commenti e amp; modifiche apportate al mio /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"

(Se si trattasse di una rete più pubblica, ad esempio università / grande ufficio, probabilmente utilizzerei impostazioni un po 'più rigide, ma queste mi stanno bene.)

Dopo un riavvio, ho eseguito l'accesso con nxclient all'impostazione desktop 'shadow' (visualizzazione nativa) e ho ottenuto GDM! : D

Purtroppo gli appunti non funzionano nella sessione 'shadow' (Funziona con gli altri / quelli normali)

[EDIT 2011-06-11]
Siamo imbattuti in Xvfb ma ha gli stessi problemi se usato in questo modo:

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
    
posta DM8 10.06.2011 - 02:22
fonte

3 risposte

5

Ho individuato il colpevole.
Testato su una nuova installazione, ha confermato che si tratta di un bug.

Ho inviato un rapporto bug

In breve il problema è: la finestra di dialogo di autenticazione del polkit apparirà su DISPLAY: 0 invece di DISPLAY: 1 dove si trova la sessione VNC / NX.

Una soluzione potrebbe essere quella di usare libpam-keyring per autenticarsi all'accesso.
o ... grattate che, probabilmente non lo fareste, una modifica per tutte le impostazioni del kit di politiche da 'auth_admin' a solo 'sì' probabilmente risolverebbe il problema, e che ovviamente renderebbe la policyKit del tutto comune ... sospiro

    
risposta data DM8 16.06.2011 - 01:52
fonte
2

Penso che questo sia il comportamento di PolicyKit corretto.

I criteri per Attivo , Inattivo e Qualsiasi altro utente sono diversi, quindi quando sei connesso tramite NX non sei Attivi (client in sessioni attive su console locali), né Inactive (client in sessioni inattive su console locali), ma risultano come Qualsiasi utente.

È possibile visualizzare la politica predefinita per l'azione sotto il controllo della politica per il diverso tipo di utenti con il comando

pkaction --verbose

Come puoi vedere, l'utente di tipo Qualsiasi è limitato rispetto agli utenti attivi.

Per rimediare, puoi modificare la politica di default. Di seguito suggerisco uno script awk per creare un file del kit di criteri da inserire nella giusta posizione. Questo è lo script:

#!/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 } } }

Supponi di chiamarlo create-policy . Rendilo eseguibile, esegui lo script con

%pre%

quindi sposta il file risultante:

%pre%

Ora dovresti avere lo stesso diritto di un utente della sessione locale.

    
risposta data enzotib 21.07.2011 - 22:29
fonte
0

Stavo incontrando un problema simile con NX e ho trovato il seguente thread:

Perché ottengo Unity invece di Classico quando si utilizza NX?

Ho modificato il mio client Windows NX in modo che il desktop sia impostato su Unix e amp; Personalizzato, quindi impostalo per eseguire il seguente comando:

gnome-session --session=classic-gnome

E selezionato Nuovo desktop virtuale .
Dopo quello ero buono per andare.

    
risposta data David B 21.07.2011 - 20:37
fonte

Leggi altre domande sui tag