it-swarm-eu.dev

comment utiliser xauth pour exécuter une application graphique via un autre utilisateur sous linux

Mon compte utilisateur habituel est, disons, utilisateur1. J'ai créé user2 distinct pour une application x que j'aimerais exécuter tout en étant connecté à x en tant qu'utilisateur1, mais d'une manière qui l'empêchera d'accéder en lecture/écriture aux données de user1. Je pensais que je pouvais utiliser xauth et Sudo/su pour user2 de user1 pour exécuter cette application. Comment puis-je faire cela? Je ne sais pas comment configurer xauth.

48
Phil

J'ai trouvé quelque chose qui fonctionne très bien pour moi sur KDE

kdesu -u username /path/to/program
2
Phil

Pour utiliser xauth sélectivement lors de l'exécution de user1:

xauth list|grep `uname -n`

Ceci imprime les entrées d'autorisation de clé hexagonale pour vous. Vous pourriez avoir également différents affichages associés à ces hôtes.

En tant qu'utilisateur2 définissez votre affichage (en supposant le cas par défaut):

DISPLAY=:0; export DISPLAY

Exécutez ensuite:

xauth add $DISPLAY . hexkey

Notez le point après $ DISPLAY et avant la clé hexagonale.

Lorsque l'accès n'est plus nécessaire, en tant qu'utilisateur2, vous pouvez exécuter:

xauth remove $DISPLAY
33
Randall

Je mets mon .zshrc une ligne avec export XAUTHORITY=~/.Xauthority et maintenant je peux exécuter Sudo -E xcommand. Après beaucoup de recherches sur Google, c'était pour moi le moyen le plus simple.

12
kfl62

Premièrement: n'utilisez pas xhost +, c'est plutôt peu sûr (couverture autoriser/refuser).

Utilisez plutôt le mécanisme X-Cookie:

su user2
cp /home/user1/.Xauthority /home/user2/.Xauthority 
export DISPLAY=:0

Sinon, si vous avez sux installé, utilisez-le (voir la réponse d'ehempel).

Dans les deux cas, user2 utilisera le cookie secret dans .Xauthority pour autoriser le serveur X, et personne d'autre n'y aura accès.

Remarques:

  • Selon vos autorisations de fichier, vous devrez peut-être copier .Xauthority d'une autre manière.
  • Au lieu de copier .Xauthority, vous pouvez également utiliser xauth pour extraire et copier la clé d'autorisation (voir la réponse de Randall). Si vous avez plusieurs clés dans le .Xauthority fichier c'est plus sélectif; sinon c'est une question de goût.
9
sleske

En supposant debian ou ubuntu (devrait être similaire sur Red Hat/SUSE).

Sudo apt-get install sux
sux user -c 'command'
9
ehempel

Cela résoudra le problème pour tous les utilisateurs:

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF
7
JMS

En tant que root:

xhost local:yourusername

Où votre nom d'utilisateur est votre nom d'utilisateur :)

Ensuite, faites su car votre utilisateur xclock devrait fonctionner s'il est installé

4
ACV

Ce ne sont que des hacks:

  • xauth + (non sécurisé)
  • ssh -X user2 @ localhost (moche)

sleske ci-dessus a, je pense, la bonne solution.

2
alex

Cette manière faite dans suse/opensuse: http://www.novell.com/support/kb/doc.php?id=700374

Modifiez simplement le /etc/pam.d/su, en ajoutant l'option (en gras):

session facultative pam_xauth.so systemuser = 1

Ensuite, vous pouvez basculer avec su sans -:

su user2

et exécutez l'application graphiquement.

0
pojem