web-dev-qa-db-fra.com

Exécution d'une application GUI en tant qu'un autre utilisateur (non root)

Disons que j'ai 2 comptes d'utilisateurs user1 et user2. Lorsque je me connecte en tant que user1, puis passez à user2 en utilisant su, je peux exécuter des programmes en ligne de commande, mais les programmes GUI échouent.

Exemple:

user1@laptop:~$ su - user2
user2@laptop:~$ leafpad ~/somefile.txt
No protocol specified
leafpad: Cannot open display:

Alors, comment puis-je exécuter une application GUI?

shellx11xorgsu
36
sashoalm

su vs su -

Lorsque vous devenez un autre utilisateur, vous voulez généralement utiliser su - user2. Le tiret forcera le .bash_profile De l'utilisateur2 à se trouver.

xhost

De plus, vous devrez autoriser les utilisateurs à accéder à votre écran. Ceci est régi par X. Vous pouvez utiliser la commande xhost + Pour autoriser les autres utilisateurs à afficher les interfaces graphiques sur le bureau de l'utilisateur1.

REMARQUE: Lorsque vous exécutez xhost +, Vous voudrez l'exécuter tout en restant dans un shell appartenant à user1.

$ AFFICHER

Lorsque vous devenez utilisateur2, vous devrez peut-être définir la variable d'environnement $DISPLAY.

$ export DISPLAY=:0.0
43
slm

Vous devez partager le jeton d'authentification de ser1 (en supposant que ~est le domicile de ser1):

cat ~/.Xauthority | Sudo -u user2 -i tee .Xauthority > /dev/null
10
user4674453

Vous pouvez utiliser le transfert X11:

ssh -XY otheruser@localhost your-gui-program-name-here
10
Michael Franzl

Vous pouvez démarrer l'application à partir d'un autre utilisateur. Je vais démarrer l'application gimp à partir de l'utilisateur 2, tout en étant connecté (GUI) avec l'utilisateur 1:

$ xhost +
$ Sudo su user2

(entrez pass)

$ gimp

Prendre plaisir :)

6
Antoni Stavrev

Vous pouvez essayer la commande sux:

sux user2

sux gérera les trucs $ DISPLAY pour vous. Vous devrez peut-être l'installer avec:

Sudo apt-get install sux

sous Debian/Ubuntu.

4
phil

Comme alternative à sux, pour exécuter en toute sécurité une commande graphique (firefox-esr dans l'exemple ci-dessous) comme $AUTHUSER (guest dans l'exemple ci-dessous):

AUTHUSER=guest
AUTHSTRING=SI:localuser:${AUTHUSER}
xhost +${AUTHSTRING} > /dev/null
Sudo_ASKPASS=/usr/bin/ssh-askpass
export Sudo_ASKPASS
Sudo -k --askpass -u ${AUTHUSER} /usr/bin/firefox-esr
xhost -${AUTHSTRING} > /dev/null
Sudo -K

le code fait:

  1. donne à l'utilisateur guest accès à votre utilisateur actuel $DISPLAY via xhost +SI:localuser:guest
  2. utilise ssh-askpass pour vous demander graphiquement un mot de passe (bien sûr, vous pouvez utiliser sudoers(5)NOPASSWD: pour éviter cela, si votre politique de sécurité pense que c'est correct. Ou vous pourriez utilisez d'autres programmes askpass ou spécifiez-les dans des fichiers de configuration (voir Sudo(8) pour plus de détails sur --askpass)
  3. si le mot de passe est correct (et que vous avez des autorisations dans sudoers(5)), il exécute la commande /usr/bin/firefox-esr en tant qu’autre utilisateur (guest)
  4. une fois le programme terminé, les autorisations accordées à un autre utilisateur (guest) pour accéder à votre $DISPLAY sont révoquées via xhost -SI:localuser:guest

  5. enfin, Sudo -K supprime le mot de passe mis en cache, donc la prochaine invocation de ssh-askpass vous demandera à nouveau le mot de passe (au lieu d'utiliser le mot de passe mis en cache)

    bien que ce soit un peu plus de travail que ce que gksu(8) ou sux(8) a fait, il peut être scripté, et il est beaucoup plus sûr que:

    • xhost + (tout utilisateur aura accès à votre affichage graphique tant qu'il sera en vigueur)
    • lisible ~/.xauth par d'autres utilisateurs (accès illimité par cet utilisateur à votre écran)
    • ce que gksu/sux a fait (copie temporaire de ~/.Xauthority, qui a permis à l'utilisateur spécifié de copier votre MIT-MAGIC-COOKIE-1 et de continuer à utiliser votre écran même après gksu/Sux terminé (tant que vous n'avez pas éteint la machine ou déconnecté de l'affichage - les économiseurs d'écran, l'hibernation, etc. n'ont pas changé le cookie magique).

car il n'autorisera qu'un seul utilisateur local à accéder à votre écran, puis uniquement tant que la commande s'exécutera (à la fin de la commande, $AUTHUSER ne pourra plus accéder à votre écran de quelque manière que ce soit).

Une autre alternative sûre est ssh -X (sans -Y qui vous rend en fait moins sûr! Voir ForwardX11Trusted dans ssh_config(5) pour plus de détails), comme il est plus facile de à utiliser si vous ne l'écrivez pas, mais cela induit une surcharge supplémentaire (par exemple, il est plus lent) et certains programmes pourraient ne pas fonctionner correctement sans dangereux-Y.

0
Matija Nalis