come usare xauth per eseguire applicazioni grafiche tramite altri utenti su linux

48

Il mio account utente normale è, diciamo, utente1. Ho creato user2 separato per alcune applicazioni x che vorrei eseguire mentre accedevo a x come user1 ma in modo da impedirgli di accedere in lettura / scrittura ai dati user1. Ho pensato che avrei potuto usare xauth e sudo / su a user2 da user1 per eseguire questa applicazione. Come faccio a fare questo? Non sono sicuro di come configurare xauth.

linux sudo

— Phil
fonte

32

Per usare xauth in modo selettivo, mentre l'utente1 esegue:

xauth list|grep `uname -n`

Questo stampa le voci di autorizzazione hexkey per te. Si potrebbe avere diversi display connessi con questi host pure.

Come utente2 imposta il display (presupponendo il caso predefinito):

DISPLAY=:0; export DISPLAY

Quindi eseguire:

xauth add $DISPLAY . hexkey

Nota il punto dopo $ DISPLAY e prima dell'esagono.

Quando l'accesso non è più necessario, come utente2 è possibile eseguire:

xauth remove $DISPLAY

— Randall
fonte

Problema 1: user2 non ha .Xauthorityfile nella home directory dell'utente2. Problema 2: in qualche modo e per qualche motivo non capisco, dopo su, XAUTHORITY mantiene il percorso del file su user1. Ma quel file non è leggibile da user2.

— Otheus,

Sembra che ti sei dimenticato unset XAUTHORITY sotto user2

— socketpair il

è hexkeynel xauth addcomando lo stesso di xauth listo devo crearne uno nuovo casuale?

— bonanza,

bonanza: è quello in uscita dalla lista xauth.

— John Eikenberry,

1

Un altro modo per farlo è quello di ... "estratto xauth - $ DISPLAY | sudo -iu steam xauth merge -". In questo caso ho XAUTHORITY impostato in .profile, quindi 'sudo -i' ha impostato correttamente.

— John Eikenberry,

12

Ho inserito .zshrcuna mia riga export XAUTHORITY=~/.Xauthoritye ora sono in grado di eseguire sudo -E xcommand. Dopo aver cercato su Google, per me questo è stato il modo più semplice.

— kfl62
fonte

1

Si noti che questa procedura normalmente non richiede l'utilizzo sudo -E(e l'utilizzo -Eè disabilitato sulla maggior parte delle installazioni predefinite) poiché normalmente la sudoersconfigurazione predefinita consentirebbe il passaggio XAUTHORITYdella variabile di ambiente su sudo.

— Guss,

@Guss Non richiede -E . Può essere impostato come una variabile che può essere passata e Red Hat o Debian lo suggeriscono.

— Daniel C. Sobral,

@ DanielC.Sobral - è quello che ho detto :-)

— Guss,

@Guss Oh, scusa. In qualche modo ho invertito ogni frase che hai scritto. :-)

— Daniel C. Sobral,

Ancora non ha funzionato per me, su Mac OS X con zsh

— Sridhar Sarnobat,

9

Supponendo che debian o ubuntu (dovrebbe essere simile su Red Hat / SUSE).

sudo apt-get install sux
sux user -c 'command'

— ehempel
fonte

+1 buona risposta, inutile reinventare la ruota. Per inciso, sux fa principalmente quello che suggerisce la mia risposta sopra. Naturalmente è più potente e più facile da usare.

— sleske,

Si può notare che 'sux' in effetti è anche un semplice script di shell ..

— Martin Mächler,

5

suxnon viene mantenuto (e rimosso dai repository di Debian / Ubuntu): pacchetti.qa.debian.org/s/sux/news/20140101T172633Z.html

— Rob W

9

Primo: non usare xhost +, è piuttosto insicuro (la coperta consente / nega).

Piuttosto usa il meccanismo X-Cookie:

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

In alternativa, se hai suxinstallato, usa quello (vedi la risposta di ehempel).

In entrambi i casi user2 utilizzerà il cookie segreto in .Xauthority per autorizzare il server X e nessun altro avrà accesso ad esso.

Appunti:

A seconda delle autorizzazioni dei file, potrebbe essere necessario copiare .Xauthority in qualche altro modo.
Invece di copiare .Xauthority, puoi anche usare xauthper estrarre e copiare la chiave di autorizzazione (vedi la risposta di Randall). Se hai più chiavi nel .Xauthorityfile, questo è più selettivo; altrimenti è una questione di gusti.

— sleske
fonte

sì, ho accesso root su quella macchina

— Phil

Si tratta semplicemente di copiare manualmente i cookie xauth tramite l'accesso root. Questo non è diverso dall'uso di xauth come spiega Randall nella risposta (attuale) in alto, tranne per il fatto che copia tutti i cookie mostrati da "xauth list". Quindi questo è meno sicuro della risposta xauth in alto che aggiungerebbe solo i cookie che scegli.

— John Eikenberry,

@JohnEikenberry: Vero, grazie per averlo segnalato. Ho aggiornato la mia risposta.

— sleske,

7

Questo risolverà il problema per tutti gli utenti:

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

— JMS
fonte

Questo è fondamentalmente quello che ho fatto e funziona benissimo, grazie!

— Guss,

4

Come root:

xhost local:yourusername

Dove yourusername è il tuo nome utente :)

Quindi fai su come l'utente xclockdovrebbe funzionare se è installato

— ACV
fonte

2

Questi sono solo hack:

xauth + (non sicuro)
ssh -X user2 @ localhost (brutto)

sleske sopra ha, penso, la soluzione adeguata.

— alex
fonte

ssh -Xè una soluzione molto semplice ed elegante, non dipendente da alcun elemento gtk / kde deprecato / non mantenuto (che richiede l'installazione di più binari con bit SUID ...).

— Stefan

2

Ho trovato qualcosa che funziona alla grande su KDE

kdesu -u username /path/to/program

— Phil
fonte

Da parte debian di kde-cli-tools, e non in $PATHma in /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(ovviamente a seconda dell'architettura).

— Stefan

0

In questo modo realizzato in suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

Semplicemente modificando /etc/pam.d/su, aggiungendo l'opzione (grassetto):

sessione opzionale pam_xauth.so systemuser = 1

Quindi puoi passare a su senza -:

su user2

ed esegui graficamente l'app.

— Pojem
fonte

-1

Per GNOME (e senza alcun ambiente desktop davvero, Io lo uso con icewm solo) gksu:

gksu -u username program

— Matija Nalis
fonte

"gksu è stato deprecato per anni": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

— Stefan

@Stefan nota che questo bug di Debian riguarda la premessa che elevare i privilegi per l' intero programma è una cattiva idea, e che il programma dovrebbe invece essere modificato per eseguire solo helper minimi con privilegi elevati (usando PolicyKit). Questa domanda (e la mia risposta) riguarda la riduzione dei privilegi, che è un'altra cosa del tutto e in effetti una buona idea (ad esempio, per la navigazione casuale ho un collegamento che esegue Firefox con un account meno privilegiato rispetto al mio predefinito, quindi qualsiasi exploit lì può toccherò i miei dati - e gksu (8) va bene per quello)

— Matija Nalis

Tutto ciò va bene, ma usare un binario SUID deprecato e non mantenuto è semplicemente sbagliato. Questa risposta potrebbe essere stata utile in passato, ma non lo è più.

— Stefan,