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

34

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?

sashoalm
la source
L'une des principales raisons, j'ai trouvé, que cela échoue est parce qu'il $XAUTHORITYest toujours défini sur user1 ~/.Xauthority, que le programme, je suppose, essaiera de lire, et il échoue parce que ce fichier a généralement le mode 0600 ( -rw-------), ce qui signifie qu'il n'est pas disponible pour la lecture par n'importe qui dans le groupe "autre", qui inclut user2. Ce qui signifie que si vous chmod o+r ~/.Xauthority(en tant qu'utilisateur1), vous aurez contourné ce problème. J'ai écrit un script qui le démontre.
Braden Best

Réponses:

42

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
slm
la source
1
xhost +user2me donne toujours cette erreur - xhost: bad hostname "user2". J'ai googlé certains, et il semble que je doive le faire xhost +user2@laptopou xhost +user2@localhost, je ne sais pas lequel. Ensuite, il dit xhost +user2@localhost being added to access control list.
sashoalm
1
Mais même après avoir ajouté l'utilisateur avec xhostet spécifié export DISPLAY=:0.0, l'exécution leafpadme donne toujours No protocol specified leafpad: Cannot open display:et ne fonctionne pas. J'ai trouvé ce lien sur linuxquestions.org/questions/linux-newbie-8/… , qui dit qu'il y a des cookies magiques et xauth. Avez-vous testé que ces choses fonctionnent sur votre ordinateur? Peut-être que quelque chose est différent avec ma configuration? Je suis sur Debian + LXDE.
sashoalm
1
Merci, ça xhost +marche et rien d'autre ne semble nécessaire (pas besoin de régler $DISPLAY). Pouvez-vous mettre à jour votre réponse et je l'accepterai?
sashoalm
5
Oh, j'ai trouvé quelque chose. Sur Fedora 21, l'exécution xhostdonne une liste au format SI:localuser:USERNAME, donc ça xhost SI:localuser:user2devrait marcher. Oh et l'affichage de l'utilisateur peut être trouvé en utilisant w.
Wilf
7
xhost +permettra à tout utilisateur de n'importe quel hôte pouvant se connecter à votre x-server d'accéder à votre écran. xhost +SI:localuser:user2fonctionne pour moi sur Debian.
robartsd
9

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
user4674453
la source
1
C'est la seule réponse qui a fonctionné pour moi (Ubuntu 14).
sudo
Cette solution fonctionne bien à partir de la machine distante (= client X Win) tandis que les solutions xhost des autres réponses doivent être exécutées sur la machine locale (= serveur X Win).
Jpsy
Il pourrait être plus sûr à utiliser tee -apour éviter d'altérer toute information existante dans  .Xauthority.
Scott
7

Vous pouvez utiliser le transfert X11:

ssh -XY otheruser@localhost your-gui-program-name-here
Michael Franzl
la source
Ceci est une solution brillante. Le plus simple que j'ai lu jusqu'à présent. Beaucoup plus de gens connaissent ssh que la configuration x11.
Alexis Panagiotopoulos
6

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 :)

Antoni Stavrev
la source
4
C'est la même chose que la réponse acceptée de quatre ans.
G-Man dit `` Réinstalle Monica ''
pouvez-vous dire un meilleur moyen rapide?
Antoni Stavrev
J'ai toujours utilisé cette méthode, mais elle ne fonctionne plus pour moi avec Debian et Xfce. ( correction : cela fonctionne, mais je dois d' export DISPLAYabord, comme le dit la réponse acceptée)
giusti
après avoir $ xhost -
terminé
4

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.

phil
la source
4
suxn'est plus fourni par Debian ou Ubuntu. La meilleure alternative que j'ai pu trouver est d'ajouter xhost SI:localuser:root(ou n'importe quel utilisateur) pour ~/.xprofilelui permettre de façon permanente ou pour l'utiliserrunuser
stefanct
Jusqu'à et y compris Debian Stretch, il y avait gksu/ gksudoalternative qui fonctionnait bien. Bien qu'il soit toujours dans Sid, il est supprimé dans Buster pour des problèmes de sécurité.
Matija Nalis
0

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 .

Matija Nalis
la source
-1

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.

Récolte 1018
la source
(1) Il n'y a rien dans cette question qui nécessite l'exécution en tant que root, ou où l'exécution en tant que root est bénéfique. (1b) Si quoi que ce soit, l'exécution en tant que root peut simplement confondre les choses. (2) Il y a rarement (voire jamais) de raison d'utiliser sudo su. Utilisez  sudoou  su; choisissez-en un. (3) La question est rédigée en termes de  user1et  user2. Veuillez écrire votre réponse en termes de  user1et  user2. (Faites ou ne faites pas; il n'y en a pas  tri.) (4) Votre réponse serait meilleure si elle comprenait une explication de  SI:localuser. ………………… Veuillez ne pas répondre dans les commentaires; éditez  votre réponse pour la rendre plus claire et plus complète.
Scott