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

Disons que j'ai 2 comptes d'utilisateurs user1et user2. Lorsque je me connecte en tant que user1, puis passe à l' user2utilisation 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?

su vs su -

Lorsque vous devenez un autre utilisateur, vous souhaitez généralement l'utiliser su - user2. Le tiret forcera l'utilisateur2 .bash_profileà 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: lors de l'exécution, xhost +vous voudrez l'exécuter tout en restant dans un shell qui appartient à user1.

$ AFFICHER

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

$ export DISPLAY=:0.0

Vous avez besoin de partager l'authentification par jeton de la user1 ( en supposant ~est la maison de user1 ):

cat ~/.Xauthority | sudo -u user2 -i tee .Xauthority > /dev/null

Vous pouvez utiliser le transfert X11:

ssh -XY otheruser@localhost your-gui-program-name-here

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

$ xhost +
$ sudo su user2

(entrez pass)

$ gimp

Prendre plaisir :)

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.

Comme alternative à sux, pour exécuter en toute sécurité la commande graphique ( firefox-esrdans l'exemple ci-dessous) comme $AUTHUSER( guestdans 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' guestutilisateur l'accès à votre utilisateur actuel $DISPLAYviaxhost +SI:localuser:guest
2. utilise ssh-askpasspour 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 pouvez utiliser d'autres askpassprogrammes, ou les spécifier dans des fichiers de configuration (voir sudo(8)pour plus de détails --askpass)
3. si le mot de passe est correct (et que vous avez des autorisations sudoers(5)), il exécute la commande en /usr/bin/firefox-esrtant qu'un autre utilisateur ( guest)
4. une fois le programme terminé, les autorisations accordées à un autre utilisateur ( guest) pour accéder à votre $DISPLAYsont révoquées viaxhost -SI:localuser:guest

5. enfin, sudo -Ksupprime le mot de passe mis en cache, donc la prochaine invocation de ssh-askpassvous demandera à nouveau le mot de passe (au lieu d'utiliser le mot de passe mis en cache)

   alors qu'il est un peu plus de travail que ce gksu(8)ou a sux(8)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)
   • quoi gksu/ suxfait (copie temporaire de ~/.Xauthority, qui a permis à l'utilisateur spécifié de copier votre MIT-MAGIC-COOKIE-1et de continuer à utiliser votre écran même après la fin de gksu / sux (tant que vous n'avez pas arrêté la machine ou déconnecté de l'affichage - les économiseurs d'écran, l'hibernation, etc. n'ont pas changé la magie) biscuit).

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, $AUTHUSERne pourra plus accéder à votre écran de quelque manière que ce soit).

Une autre alternative sûre est ssh -X(sans -Ylaquelle vous êtes en fait moins sécurisé! Voir ForwardX11Trusteddans ssh_config(5)pour plus de détails), car il est plus facile à utiliser si vous ne l'écrivez pas, mais il induit une surcharge supplémentaire (par exemple, il est plus lent) et certains programmes peuvent ne pas fonctionner correctement sans danger -Y .

Vous devez charger l'interface utilisateur d'installation en tant qu'utilisateur2 .

Essayez de suivre ceci:

Connectez-vous en tant que root :

sudo su

Testez le serveur x:

xclock

Si vous pouvez voir une horloge fonctionner, c'est bon, essayez maintenant d'exécuter ceci:

xhost

Le résultat devrait ressembler à ceci:

xhost SI:localuser:tri
# tri is my user name

Maintenant, laissez user2 accéder à xhost

xhost +SI:localuser:user2

essayez maintenant de vous connecter à nouveau à user2 et essayez d'ouvrir n'importe quel programme GUI.