วิธีใช้ xauth เพื่อรันแอปพลิเคชั่นแบบกราฟิกผ่านผู้ใช้รายอื่นบน linux

48

บัญชีผู้ใช้ปกติของฉันคือสมมุติว่า user1 ฉันสร้าง user2 แยกต่างหากสำหรับแอปพลิเคชั่น x บางตัวที่ฉันต้องการเรียกใช้ขณะที่ล็อกอินเป็น x ในฐานะผู้ใช้ 1 แต่ในทางที่จะป้องกันไม่ให้ผู้ใช้เข้าถึง / อ่านข้อมูล user1 ฉันคิดว่าฉันสามารถใช้ xauth และ sudo / su กับ user2 จาก user1 เพื่อเรียกใช้แอปพลิเคชันนี้ ฉันจะทำสิ่งนี้ได้อย่างไร ฉันไม่แน่ใจวิธีกำหนดค่า xauth

linux sudo

— ฟิล
แหล่งที่มา

32

ในการใช้ xauth แบบเลือกให้เป็น user1 ให้รัน:

xauth list|grep `uname -n`

สิ่งนี้พิมพ์รายการการอนุญาต hexkey สำหรับคุณ คุณสามารถมีจอแสดงผลที่แตกต่างกันที่เกี่ยวข้องกับโฮสต์เหล่านั้นเช่นกัน

ในฐานะที่เป็น user2 ตั้งค่าการแสดงผลของคุณ (สมมติว่าเป็นกรณีเริ่มต้น):

DISPLAY=:0; export DISPLAY

จากนั้นเรียกใช้:

xauth add $DISPLAY . hexkey

สังเกตจุดหลัง $ DISPLAY และหน้า hexkey

เมื่อไม่ต้องการเข้าถึงอีกต่อไปในฐานะผู้ใช้ 2 คุณสามารถเรียกใช้:

xauth remove $DISPLAY

— แรนดัล
แหล่งที่มา

ปัญหาที่ 1: user2 ไม่มี.Xauthorityไฟล์ในโฮมไดเรกทอรีของ user2 ปัญหาที่ 2: อย่างใดและด้วยเหตุผลบางอย่างที่ฉันไม่เข้าใจหลังจากsuXAUTHORITY ถือพา ธ ของไฟล์ไปที่ user1 แต่ไฟล์นั้นไม่สามารถอ่านได้โดย user2

— Otheus

ดูเหมือนว่าคุณลืม unset XAUTHORITY ภายใต้ user2

— socketpair

คือhexkeyในxauth addคำสั่งเดียวกับจากxauth listหรือฉันจะต้องสร้างแบบสุ่มใหม่?

— โบนันซ่า

โบนันซ่า: มันเป็นเอาท์พุทเดียวจากรายการ xauth

— John Eikenberry

1

อีกวิธีในการทำเช่นนี้คือ ... "xauth extract - $ DISPLAY | sudo -iu steam xauth merge -" ในกรณีนี้ฉันมี XAUTHORITY ตั้งค่าเป็น. profile ดังนั้น 'sudo -i' จึงได้รับชุดนั้น

— John Eikenberry

12

ฉันใส่.zshrcสายของฉันด้วยexport XAUTHORITY=~/.Xauthorityและตอนนี้ฉันสามารถดำเนินการsudo -E xcommandได้ หลังจาก Googling มามากสำหรับฉันนี่เป็นวิธีที่ง่ายที่สุด

— kfl62
แหล่งที่มา

1

โปรดทราบว่าขั้นตอนนี้โดยปกติจะไม่ต้องการให้คุณใช้sudo -E(และการใช้-Eงานถูกปิดใช้งานในการติดตั้งเริ่มต้นส่วนใหญ่) เพราะปกติแล้วการsudoersกำหนดค่าเริ่มต้นจะอนุญาตให้XAUTHORITYส่งผ่านตัวแปรสภาพแวดล้อมไปยัง sudo

— Guss

@Guss มันไม่จำเป็นต้องมี -Eสามารถตั้งค่าเป็นตัวแปรที่สามารถส่งผ่านได้และ Red Hat หรือ Debian จะแนะนำให้ใช้

— Daniel C. Sobral

@ DanielC.Sobral - นั่นคือสิ่งที่ฉันพูดว่า :-)

— Guss

@Guss โอ้ขอโทษ ฉันกลับทุกประโยคที่คุณเขียน :-)

— Daniel C. Sobral

ยังไม่ได้ผลสำหรับฉันใน Mac OS X ที่มี zsh

— Sridhar Sarnobat

9

สมมติว่า debian หรือ ubuntu (ควรคล้ายกับ Red Hat / SUSE)

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

— ehempel
แหล่งที่มา

+1 คำตอบที่ดีไม่มีประเด็นในการสร้างวงล้อ บังเอิญ sux ส่วนใหญ่ทำในสิ่งที่คำตอบของฉันแสดงให้เห็นข้างต้น มันมีประสิทธิภาพและใช้งานง่ายกว่าแน่นอน

— sleske

คุณอาจสังเกตได้ว่า 'sux' เป็นสคริปต์เชลล์แบบง่าย ๆเช่นกัน ..

— Martin Mächler

5

suxถูกทำให้หมดกำลังใจ (และนำออกจากที่เก็บของ Debian / Ubuntu): packages.qa.debian.org/s/sux/news/20140101T172633Z.html

— Rob W

9

ครั้งแรก: อย่าใช้xhost +มันค่อนข้างจะไม่ปลอดภัย (มีผ้าห่มให้ / ปฏิเสธ)

ค่อนข้างใช้กลไก X-Cookie:

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

หรือหากคุณsuxติดตั้งไว้ให้ใช้ (ดูคำตอบของ ehempel)

ในทั้งสองกรณี user2 จะใช้คุกกี้ลับใน. Xauthority เพื่ออนุญาตให้เซิร์ฟเวอร์ X และไม่มีใครสามารถเข้าถึงได้

หมายเหตุ:

คุณอาจต้องคัดลอก. Xauthority ด้วยวิธีอื่นทั้งนี้ขึ้นอยู่กับสิทธิ์อนุญาตไฟล์ของคุณ
แทนที่จะคัดลอก.Xauthorityคุณสามารถใช้xauthเพื่อแยกและคัดลอกคีย์การอนุญาต (ดูคำตอบของ Randall) หากคุณมีหลายคีย์ใน.Xauthorityไฟล์นี่จะเป็นการเลือกที่ดีกว่า มิฉะนั้นมันเป็นเรื่องของรสนิยม

— sleske
แหล่งที่มา

ใช่ฉันมีการเข้าถึงรากในเครื่องที่

— ฟิล

นี่เป็นเพียงการคัดลอกคุกกี้ xauth ด้วยตนเองผ่านการเข้าถึงรูท นี่ไม่ต่างจากการใช้ xauth ตามที่ Randall อธิบายไว้ในคำตอบยอดนิยม (ปัจจุบัน) ยกเว้นว่าจะคัดลอกทุกคุกกี้ที่ 'รายการ xauth' จะแสดง ดังนั้นนี่คือความปลอดภัยน้อยกว่าคำตอบ xauth ด้านบนซึ่งจะเพิ่มเฉพาะคุกกี้ที่คุณเลือก

— John Eikenberry

@ JohnEikenberry: จริงขอบคุณที่ชี้ให้เห็น ฉันปรับปรุงคำตอบของฉัน

— sleske

7

วิธีนี้จะแก้ไขปัญหาสำหรับผู้ใช้ทั้งหมด:

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

— JMS
แหล่งที่มา

นี่เป็นสิ่งที่ฉันได้ทำไปแล้วและมันใช้งานได้ดีมากขอบคุณ!

— Guss

3

ในฐานะที่เป็นราก:

xhost local:yourusername

ชื่อผู้ใช้ของคุณอยู่ที่ไหน :)

จากนั้นทำ su ตามที่ผู้ใช้ของคุณ xclockควรทำงานหากติดตั้งไว้

— ACV
แหล่งที่มา

2

นี่เป็นเพียงการแฮ็ก:

xauth + (ไม่ปลอดภัย)
ssh -X user2 @ localhost (น่าเกลียด)

ฉันคิดว่า sleske ด้านบนมีทางออกที่เหมาะสม

— อเล็กซ์
แหล่งที่มา

ssh -Xเป็นวิธีที่ง่ายและสง่างามไม่ได้ขึ้นอยู่กับสิ่ง gtk / kde ที่เลิกใช้ / ไม่ได้ใช้ (ซึ่งต้องติดตั้งไบนารีเพิ่มเติมด้วยบิต SUID ... )

— Stefan

2

ฉันพบสิ่งที่ใช้งานได้ดีสำหรับฉันใน KDE

kdesu -u username /path/to/program

— ฟิล
แหล่งที่มา

ในส่วน debian ของkde-cli-toolsและไม่ได้อยู่ใน$PATHแต่ใน/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(ชัดขึ้นอยู่กับสถาปัตยกรรม)

— Stefan

0

วิธีนี้ทำใน suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

เพียงแก้ไข /etc/pam.d/su โดยเพิ่มตัวเลือก (ตัวหนา):

เซสชันเสริม pam_xauth.so systemuser = 1

จากนั้นคุณสามารถสลับกับ su โดยไม่ต้อง -:

su user2

และเรียกใช้แอพแบบกราฟิก

— pojem
แหล่งที่มา

-1

สำหรับ GNOME (และไม่มีสภาพแวดล้อมเดสก์ทอปใด ๆ จริง ๆ ฉันใช้กับ icewm เท่านั้น) gksu:

gksu -u username program

— Matija Nalis
แหล่งที่มา

"gksu เลิกใช้มานานหลายปีแล้ว": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

— Stefan

@Stefan โปรดทราบว่าข้อบกพร่องของ Debian นี้เกี่ยวกับหลักฐานว่าการยกระดับสิทธิ์สำหรับโปรแกรมทั้งหมดเป็นความคิดที่ไม่ดีและควรแก้ไขโปรแกรมเพื่อให้ผู้ช่วยเหลือขั้นต่ำมีสิทธิ์ยกระดับแทน (ใช้ PolicyKit) แทน คำถามนี้ (และคำตอบของฉัน) เกี่ยวกับการลดสิทธิ์ซึ่งเป็นอีกสิ่งหนึ่งโดยสิ้นเชิงและในความเป็นจริงความคิดที่ดี (ตัวอย่างเช่นสำหรับการเรียกดูแบบสุ่มฉันมีทางลัดที่เรียกใช้ Firefox ในบัญชีที่มีสิทธิ์น้อยกว่า สัมผัสข้อมูลของฉัน - และ gksu (8) ค่อนข้างดีสำหรับเรื่องนั้น)

— Matija Nalis

สิ่งที่ดี แต่การใช้ไบนารี SUID ที่คัดค้านและไม่ได้ใช้นั้นผิด คำตอบนี้อาจมีประโยชน์ในอดีต แต่ไม่ใช่อีกต่อไป

— Stefan