cara menggunakan xauth untuk menjalankan aplikasi grafis melalui pengguna lain di linux

48

Akun pengguna reguler saya adalah, katakanlah, user1. Saya membuat user2 terpisah untuk beberapa aplikasi x yang ingin saya jalankan ketika sedang login ke x sebagai user1 tetapi dengan cara yang akan mencegahnya dari akses baca / tulis ke data user1. Saya pikir saya bisa menggunakan xauth dan sudo / su untuk user2 dari user1 untuk menjalankan aplikasi ini. Bagaimana saya melakukan ini? Saya tidak yakin cara mengkonfigurasi xauth.

linux sudo

— Phil
sumber

32

Untuk menggunakan xauth secara selektif, seperti yang dijalankan pengguna1:

xauth list|grep `uname -n`

Ini mencetak entri otorisasi hexkey untuk Anda. Anda dapat memiliki tampilan berbeda yang terkait dengan host tersebut juga.

Saat user2 mengatur tampilan Anda (dengan asumsi case default):

DISPLAY=:0; export DISPLAY

Lalu lari:

xauth add $DISPLAY . hexkey

Catat titik setelah $ DISPLAY dan sebelum hexkey.

Ketika akses tidak lagi diperlukan, karena user2 Anda dapat menjalankan:

xauth remove $DISPLAY

— Randall
sumber

Masalah 1: user2 tidak memiliki .Xauthorityfile di direktori home user2. Masalah 2: Entah bagaimana dan untuk beberapa alasan saya tidak mengerti, setelah itu su, XAUTHORITY memegang filepath ke user1's. Tetapi file itu tidak dapat dibaca oleh user2.

— Otheus

Sepertinya, Anda lupa di unset XAUTHORITY bawah user2

— socketpair

adalah hexkeydalam xauth addperintah yang sama seperti dari xauth listatau apakah saya harus membuat yang baru acak?

— bonanza

bonanza: ini adalah output dari daftar xauth.

— John Eikenberry

1

Cara lain untuk melakukan ini adalah sesuatu seperti ... "ekstrak xauth - $ DISPLAY | sudo -iu steam xauth bergabung -". Dalam hal ini saya memiliki XAUTHORITY di .profile, jadi 'sudo -i' mendapatkan yang benar.

— John Eikenberry

12

Saya memasukkan .zshrcgaris saya export XAUTHORITY=~/.Xauthoritydan sekarang saya bisa mengeksekusi sudo -E xcommand. Setelah banyak googling, bagi saya ini adalah cara termudah.

— kfl62
sumber

1

Perhatikan bahwa prosedur ini biasanya tidak mengharuskan Anda untuk menggunakan sudo -E(dan menggunakan -Edinonaktifkan pada sebagian besar pemasangan default) karena biasanya sudoerskonfigurasi default akan memungkinkan XAUTHORITYvariabel lingkungan untuk diteruskan ke sudo.

— Guss

@ Guss Tidak perlu -E . Itu dapat diatur sebagai variabel yang dapat dilewati, dan Red Hat atau Debian menyarankannya.

— Daniel C. Sobral

@ DanielC.Sobral - itulah yang saya katakan :-)

— Guss

@Guss Oh, maaf. Saya entah bagaimana membalikkan setiap kalimat yang Anda tulis. :-)

— Daniel C. Sobral

Masih tidak bekerja untuk saya, di Mac OS X dengan zsh

— Sridhar Sarnobat

9

Dengan asumsi debian atau ubuntu (harus serupa pada Red Hat / SUSE).

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

— ehempel
sumber

+1 jawaban yang baik, tidak ada gunanya menciptakan kembali roda. Kebetulan, sux sebagian besar melakukan apa yang disarankan jawaban saya di atas. Ini lebih kuat dan lebih mudah digunakan tentunya.

— sleske

Anda dapat mencatat, bahwa 'sux' memang merupakan skrip shell sederhana juga ..

— Martin Mächler

5

suxtidak terawat (dan dihapus dari repositori Debian / Ubuntu): packages.qa.debian.org/s/sux/news/20140101T172633Z.html

— Rob W

9

Pertama: Jangan gunakan xhost +, itu agak tidak aman (blank allow / deny).

Alih-alih menggunakan mekanisme X-Cookie:

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

Atau, jika Anda telah suxmenginstal, gunakan itu (lihat jawaban ehempel).

Dalam kedua kasus, user2 akan menggunakan cookie rahasia di .Xauthority untuk mengotorisasi ke server X, dan tidak ada orang lain yang akan memiliki akses ke sana.

Catatan:

Bergantung pada izin file Anda, Anda mungkin harus menyalin .Xauthority dengan cara lain.
Alih-alih menyalin .Xauthority, Anda juga dapat menggunakan xauthuntuk mengekstrak dan menyalin kunci otorisasi (lihat jawaban Randall). Jika Anda memiliki beberapa kunci dalam .Xauthorityfile ini lebih selektif; kalau tidak, itu adalah masalah selera.

— sleske
sumber

ya, saya punya akses root pada mesin itu

— Phil

Ini hanya menyalin cookie xauth secara manual melalui akses root. Ini tidak berbeda dengan menggunakan xauth seperti yang dijelaskan Randall dalam jawaban teratas (saat ini), kecuali itu menyalin setiap cookie yang akan ditampilkan 'daftar xauth'. Jadi ini kurang aman daripada jawaban xauth teratas yang hanya akan menambah cookie yang Anda pilih.

— John Eikenberry

@JohnEikenberry: Benar, terima kasih telah menunjukkan ini. Saya memperbarui jawaban saya.

— sleske

7

Ini akan memperbaiki masalah untuk semua pengguna:

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

— JMS
sumber

Ini pada dasarnya adalah apa yang telah saya lakukan dan ini bekerja dengan baik, terima kasih!

— Guss

4

Sebagai root:

xhost local:yourusername

Di mana nama pengguna Anda adalah nama pengguna Anda :)

Kemudian lakukan su karena pengguna Anda xclockharus bekerja jika diinstal

— ACV
sumber

2

Ini hanya retasan:

xauth + (tidak aman)
ssh -X user2 @ localhost (jelek)

sleske di atas, saya pikir, solusi yang tepat.

— alex
sumber

ssh -Xadalah solusi yang sangat sederhana dan elegan, tidak tergantung pada hal-hal gtk / kde yang sudah usang / tidak terawat (yang membutuhkan menginstal lebih banyak binari dengan bit SUID ...).

— Stefan

2

Saya menemukan sesuatu yang sangat bagus untuk saya di KDE

kdesu -u username /path/to/program

— Phil
sumber

Pada bagian debian kde-cli-tools, dan bukan di $PATHtetapi di /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(jelas tergantung pada arsitektur).

— Stefan

0

Cara ini dibuat di suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

Cukup modifikasi /etc/pam.d/su, tambahkan opsi (cetak tebal):

session opsional pam_xauth.so systemuser = 1

Maka Anda dapat beralih dengan su tanpa -:

su user2

dan jalankan aplikasi secara grafis.

— puisi
sumber

-1

Untuk GNOME (dan tanpa lingkungan desktop apa pun, saya menggunakannya hanya dengan icewm) gksu:

gksu -u username program

— Matija Nalis
sumber

"gksu telah ditinggalkan selama bertahun-tahun": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

— Stefan

@Stefan mencatat bahwa bug Debian ini adalah tentang premis bahwa meninggikan hak istimewa untuk seluruh program adalah ide yang buruk, dan bahwa program tersebut seharusnya dimodifikasi untuk hanya menjalankan pembantu minimal dengan hak istimewa tinggi sebagai gantinya (menggunakan PolicyKit). Pertanyaan ini (dan jawaban saya) adalah tentang mengurangi hak istimewa, yang merupakan hal yang sama sekali berbeda dan pada kenyataannya ide yang baik (misalnya, untuk penelusuran acak, saya memiliki pintasan yang menjalankan firefox di bawah beberapa akun yang kurang istimewa di bawah akun default saya, sehingga setiap eksploitasi di sana dapat menyentuh data saya - dan gksu (8) cukup baik untuk itu)

— Matija Nalis

Semua itu baik-baik saja, tetapi menggunakan biner SUID yang usang dan tidak terawat hanya salah. Jawaban ini mungkin bermanfaat di masa lalu, tetapi sekarang tidak lagi.

— Stefan