Lorsque la machine est sans tête, l'utilisateur n'est plus privilégié

12

Le problème principal est: TOUTES les sessions gnome ne reposant pas sur un affichage physique / natif réel - ou l'observation de cet affichage (c'est-à-dire le mode fantôme de NXserver) - ont des privilèges défectueux. Même lorsqu'il est exécuté en tant que root!

Avez-vous des commentaires sur un moyen de corriger le comportement problématique des sessions VNC / non-shadow NX?


Je mets à niveau mon serveur sans tête Ubuntu à la maison après un long moment, et j'ai beaucoup de problèmes que je ne me souviens pas d'exister dans les versions précédentes d'Ubuntu.

Quelques détails:

  • J'ai commencé avec ubuntu-11.04-server-amd64.iso, puis j'ai installé ubuntu-desktop dessus.
  • uname -a: Linux MiddleEarth 2.6.38-8-server # 42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU / Linux
  • Le matériel est Intel D920, 2 Go de RAM, gfx est un nvidia 6600 sans ventilateur, 3xGigabit, 1x100mbit, aucun moniteur, clavier, souris attaché.

Tour 1

Pendant que je faisais le test / la configuration avec un moniteur attaché , tout était peachy, à la fois en étant assis devant ce moniteur et lorsque VNCing depuis ma machine de bureau (dans vino).

Sans moniteur, des problèmes surviennent:

[Non résolu / abandonné]

Le tout premier problème était que vino était têtu et ne souhaitait pas charger avant / pendant GDM. Mais comme il s'agit d'un système sans tête, je n'en ai pas vraiment besoin pour commencer par X par défaut (c'est-à-dire changer le niveau d'initialisation) de toute façon, c'est donc un peu théorique. Cependant, je me souviens clairement que cela était très facile à faire dans une ancienne version d'ubuntu (v9.04 je pense). Et cela a bien fonctionné; mais plus maintenant!? ... de toute façon, j'ai complètement abandonné cette idée.

[Résolu]

Ensuite, c'était Unity / Effects messing VNC (Résolu en trichant ).

[Non résolu]

À l'origine, je suis passé à NXserver en espérant que les problèmes suivants sont peut-être des problèmes de serrure ou de vino, mais pas de chance. (Remarque: lire round2)

Lors de l'accès à distance via VNC (ou NXserver), mon compte d'utilisateur perd la possibilité de monter / démonter des disques durs.

Capture d'écran: impossible de monter 750GB_RAID1

Lors de l'accès à distance via VNC (ou NXserver), mon compte d'utilisateur ne peut pas accéder à certaines options de configuration privilégiées,
quelques exemples:

  • ne peut rien faire (c'est-à-dire «ajouter» un utilisateur ou «paramètres avancés») dans «Système -> Administration -> Utilisateurs et groupes».
  • ne peut pas utiliser «déverrouiller» dans «Système -> Administration -> Écran de connexion».
  • gparted ne parvient pas à obtenir d'informations sur les systèmes de fichiers.
  • etc. (divers autres dialogues admin / config ne fonctionnent pas correctement non plus)

Je peux seulement deviner que cela a quelque chose à voir avec les privilèges utilisateur qui ne sont pas attribués correctement lorsqu'un périphérique de moniteur physique réel n'est pas connecté.
La raison pour laquelle cela se produit dans Ubuntu 11.04, quand il est sans tête, m'échappe; Je ne me souviens pas de ce comportement dans les versions précédentes d'ubuntu.

Notez que le problème de montage du disque dur n'est pas un problème pour les disques durs internes / statiques (je les ajoute simplement à fstab car ils sont statiques de toute façon). Mais vraiment une grande douleur pour les supports USB amovibles.

Le reste des problèmes, je n'ai pas compris comment résoudre ...
Je sais ce que vous pensez ... connectez-vous à ssh, sudo su et exécutez vncserver sous root entièrement?

Capture d'écran: (en tant que root) gparted ne parvient pas à trouver des informations fs

Surprise Surprise! l'interface graphique de root est également cassée: gparted ne parvient pas à obtenir des informations, l'utilisateur et les groupes sont entièrement grisés (c'est un comportement différent de celui de mon utilisateur normal). Curieusement, le programme d'administration de l'écran de connexion semble fonctionner correctement.


2ème round

(REMARQUE: je ne sais pas si cela a fait ou n'a pas fait de différence dans le résultat. À un moment donné entre le tour 1 et le tour 2, j'ai appliqué les changements mentionnés dans les messages # 21 et # 24 de ce fil )

Les sessions standard tightvnc / NXServer ont le même comportement, MAIS ...

[Solution partielle / Le problème réel est toujours là]

Dans les paramètres de connexion NXClient, lorsque je choisis le mode «ombre» (l'ombre vous attache à l'affichage natif, c'est-à-dire l'observation du bureau) ...

Tout fonctionne parfaitement à l'intérieur de cette session!

Une chose que j'ai remarquée, c'est qu'il me demande immédiatement un mot de passe pour le trousseau de clés ... peut-être que tout le gâchis a quelque chose à voir avec l'utilisation du gnome du système de trousseau de clés?

Mais, si je me connecte avec une connexion NX régulière (pas shadow), ou un vnc régulier, cela revient à avoir les mêmes problèmes.

PS Il y a quelques jours lorsque j'ai écrit round1 et round2 (je le gardais dans un fichier txt localement). Je testais diverses suggestions pour voir ce qui fonctionnerait, c'est pourquoi je ne sais pas avec certitude si la modification du périphérique VNC xorg.conf ou ce paramètre de nomodeset a fait une différence.

[EDIT 2011-06-10]

NXServer et GDM

Au moment d'écrire ces lignes, j'avais configuré le système pour une connexion automatique, c'est pourquoi la connexion fantôme fonctionnait simplement. Plus tard, lorsque j'ai désactivé cela et redémarré le système, NX a donné une erreur, mais avec un peu de recherche sur Google, j'ai trouvé ce fil

Ce sont les changements et les commentaires que j'ai faits sur mon /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 c'était un réseau plus public, c'est-à-dire université / grand bureau, j'utiliserais probablement des paramètres un peu plus stricts, mais ceux-ci me conviennent très bien.)

Après un redémarrage, je me suis connecté avec nxclient au paramètre «shadow» (affichage natif) du bureau et j'ai obtenu GDM! :RÉ

Malheureusement, le presse-papiers ne fonctionne pas dans la session 'shadow' (il fonctionne bien sur les autres / réguliers)

[EDIT 2011-06-11]
Nous sommes tombés sur Xvfb mais il a les mêmes problèmes lorsqu'il est utilisé comme ceci:

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
la source

Réponses:

5

J'ai localisé le coupable.
Testé sur une nouvelle installation, a confirmé qu'il s'agissait d'un bug.

J'ai soumis un rapport de bug

En bref, le problème est le suivant: la boîte de dialogue d'authentification polkit apparaîtra sur DISPLAY: 0 au lieu de DISPLAY: 1 où se trouve la session VNC / NX.

Une solution de contournement peut être d'utiliser libpam-keyring pour s'authentifier automatiquement lors de la connexion.
ou ... grattez cela, cela ne le ferait probablement pas, un changement pour tous les paramètres du kit de politique de 'auth_admin' à juste 'oui' résoudrait probablement le problème, et cela ferait bien sûr policyKit sans objet ... soupir

DM8
la source
1
Pouvez-vous changer votre Xorg.conf pour supprimer l'affichage: 0. Je ne vois aucune raison pour que X y court. De cette façon, VNC / NX peut prendre DISPLAY: 0?
user606723
2

Je pense que c'est le bon comportement de PolicyKit.

La stratégie pour Actif , Inactif et Tout autre utilisateur est différente, donc lorsque vous êtes connecté via NX, vous n'êtes ni Actif (clients en sessions actives sur les consoles locales), ni Inactif (clients en sessions inactives sur les consoles locales), mais vous obtenez comme N'importe quel utilisateur.

Vous pouvez voir la stratégie par défaut pour l'action sous contrôle de stratégie pour les différents types d'utilisateurs avec la commande

pkaction --verbose

Comme vous pouvez le voir, l'utilisateur de type Any est limité par rapport aux utilisateurs actifs.

Pour y remédier, vous pouvez modifier la stratégie par défaut. Dans ce qui suit, suggérez un script awk pour créer un fichier de kit de stratégie à placer au bon emplacement. Voici le script:

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

Supposons que vous l'appeliez create-policy. Rendez-le exécutable, exécutez le script avec

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

puis déplacez le fichier résultant:

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

Vous devriez maintenant avoir le même droit que vous étiez un utilisateur de session locale.

enzotib
la source
0

Je rencontrais un problème similaire avec NX et j'ai trouvé le fil suivant:

Pourquoi est-ce que j'obtiens Unity au lieu de Classic lorsque j'utilise NX?

J'ai modifié mon client Windows NX pour que le bureau soit défini sur Unix et personnalisé, puis je l'ai configuré pour exécuter la commande suivante:

gnome-session --session=classic-gnome

Et sélectionné Nouveau bureau virtuel .
Après cela, j'étais prêt à partir.

David B
la source