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

48

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

linux sudo Phil
la source

Réponses:

32

Pour utiliser xauth de manière sélective, en tant qu'utilisateur 1 , exécutez:

xauth list|grep `uname -n`

Ceci imprime les entrées d'autorisation hexkey pour vous. Vous pouvez également associer différents affichages à ces hôtes.

En tant qu'utilisateur 2, configurez votre affichage (en supposant le cas par défaut):

DISPLAY=:0; export DISPLAY

Puis lancez:

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'utilisateur 2, vous pouvez exécuter:

xauth remove $DISPLAY
Randall
la source
Problème 1: l'utilisateur 2 n'a aucun .Xauthorityfichier dans le répertoire personnel de l'utilisateur2. Problème 2: En quelque sorte et pour une raison quelconque, je ne comprends pas, après suquoi, XAUTHORITY conserve le chemin du fichier vers celui de l'utilisateur1. Mais ce fichier n'est pas lisible par l'utilisateur2.
Otheus
On dirait que vous avez oublié unset XAUTHORITY sous user2
socketpair
est la hexkeydans la xauth addcommande le même que celui de xauth listou dois - je créer un nouveau hasard?
bonanza
bonanza: c'est la seule sortie de la liste xauth.
John Eikenberry
1
Une autre façon de faire serait quelque chose comme ... "extrait de xauth - $ DISPLAY | sudo-iu steam xauth fusion -". Dans ce cas, j'ai XAUTHORITY défini dans .profile, donc le 'sudo -i' obtient cet ensemble correctement.
John Eikenberry
12

J'ai mis .zshrcune ligne avec export XAUTHORITY=~/.Xauthorityet maintenant je suis capable d'exécuter sudo -E xcommand. Après beaucoup de recherches sur Google, c'était pour moi le moyen le plus simple.

kfl62
la source
1
Notez que cette procédure ne vous oblige normalement pas à utiliser sudo -E(et que l'utilisation -Eest désactivée sur la plupart des installations par défaut) car normalement, la sudoersconfiguration par défaut permettrait à la XAUTHORITYvariable d'environnement d'être transmise à sudo.
Guss
@Guss Cela ne nécessite pas -E. Il peut être défini en tant que variable pouvant être transmise, et Red Hat ou Debian le suggère.
Daniel C. Sobral,
@ DanielC.Sobral - c'est ce que j'ai dit :-)
Guss
@Guss Oh, désolé. J'ai en quelque sorte inversé chaque phrase que vous avez écrite. :-)
Daniel C. Sobral,
Cela ne fonctionnait toujours pas pour moi, sous Mac OS X avec zsh
Sridhar Sarnobat
9

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

sudo apt-get install sux
sux user -c 'command'
ehempel
la source
+1 bonne réponse, inutile de réinventer la roue. Incidemment, sux fait principalement ce que ma réponse ci-dessus suggère. C'est plus puissant et plus facile à utiliser bien sûr.
Sleske
Vous remarquerez peut-être que 'sux' est en fait un simple script shell.
Martin Mächler Le
5
suxn'est pas maintenu (et supprimé des dépôts Debian / Ubuntu): packages.qa.debian.org/s/sux/news/20140101T172633Z.html
Rob W
9

Premièrement: n'utilisez pas xhost +, c'est plutôt peu sécurisé (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 suxinstallé, utilisez-le (voir la réponse de ehempel).

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

Remarques:

  • En fonction de vos autorisations de fichier, vous devrez peut-être copier .Xauthority d'une autre manière.
  • Au lieu de copier .Xauthority, vous pouvez également utiliser xauthpour extraire et copier la clé d'autorisation (voir la réponse de Randall). Si vous avez plusieurs clés dans le .Xauthorityfichier, cela est plus sélectif; sinon c'est une question de goût.
sleske
la source
Ouais, j'ai un accès root sur cette machine
Phil
Ceci consiste simplement à copier manuellement les cookies xauth via un accès root. Ce n'est pas différent d'utiliser xauth comme l'explique Randall dans la réponse principale (actuelle), sauf que cela copie tous les cookies que la liste xauth afficherait. Donc, cela est moins sûr que la réponse xauth en haut qui ajouterait seulement les cookies que vous choisissez.
John Eikenberry
@ JohnEikenberry: C'est vrai, merci de l'avoir signalé. J'ai mis à jour ma réponse.
Sleske
7

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

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF
JMS
la source
C'est fondamentalement ce que j'ai fait et cela fonctionne très bien, merci!
Guss
4

En tant que root:

xhost local:yourusername

Où yourusername est votre nom d'utilisateur :)

Ensuite, faites su comme votre utilisateur xclockdevrait travailler s'il est installé

ACV
la source
2

Ce ne sont que des hacks:

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

Sleske ci-dessus a, je pense, la solution appropriée.

alex
la source
ssh -Xest une solution très simple et élégante, ne dépendant d'aucun élément obsolète / non maintenu de gtk / kde (qui nécessite l'installation de plus de binaires avec le bit SUID ...).
Stefan
2

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

kdesu -u username /path/to/program
Phil
la source
Sur la partie debian de kde-cli-tools, et non dans $PATHmais dans /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(évidemment selon l'architecture).
Stefan
0

De cette façon, made in suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

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

session optionnelle pam_xauth.so systemuser = 1

Ensuite, vous pouvez passer avec su sans -:

su utilisateur2

et lancez l'application graphiquement.

pojem
la source
-1

Pour GNOME (et sans aucun environnement de bureau, je l’utilise avec icewm uniquement) gksu:

gksu -u username program
Matija Nalis
la source
"Le gksu est déconseillé depuis des années": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236
Stefan
@Stefan note que ce bogue Debian repose sur le principe selon lequel élever des privilèges pour l' ensemble du programme est une mauvaise idée et que le programme devrait plutôt être modifié pour exécuter uniquement des aides minimales avec des privilèges élevés (à l'aide de PolicyKit). Cette question (et ma réponse) concerne la réduction des privilèges, ce qui est une tout autre chose et une bonne idée (par exemple, pour la navigation aléatoire, j’ai un raccourci qui exécute firefox sous un compte moins privilégié que mon compte par défaut, afin que tout exploit puisse touchez pas mes données - et gksu (8) est tout à fait bien pour ça)
Matija Nalis
Tout cela va bien, mais utiliser un binaire SUID obsolète et non maintenu est tout simplement faux. Cette réponse aurait pu être utile dans le passé, mais ne l'est plus.
Stefan