ทำไม "sudo -u root echo` whoami` "ไม่คืนค่าราก


11

คุณใช้ sudo เพื่อรันคำสั่งในฐานะผู้ใช้รูทจริงบน Ubuntu ได้อย่างไร? ตอนแรกฉันคิดว่านี่เป็นพฤติกรรมเริ่มต้นของ sudo จนกระทั่งฉันวิ่ง:

myuser@localhost:~$ sudo echo `whoami`
myuser

myuser@localhost:~$ sudo -u root echo `whoami`
myuser

อย่างไรก็ตามนี่คือประเภทของพฤติกรรมที่ฉันต้องการ แต่ในบรรทัดเดียวเท่านั้น:

myuser@localhost:~$ sudo su -
root@localhost:~# echo `whoami`
root

11
ทำไมก้องwhoami? เพียงแค่พูดว่า sudo whoami .. คืนค่าราก
ใหม่

คำตอบ:


26

ในความเป็นจริงมันจะเรียกใช้พวกเขาเป็นราก แต่สิ่งที่เกิดขึ้นกับคุณคือมีการประเมินขีดหลังก่อนที่จะ sudoรันเนื่องจากจำเป็นต้องประเมินคำสั่ง เพิ่มเติมโดยตรงทำไมไม่เพียงแค่นี้:

sudo whoami

การwhoamiย้อนกลับของคุณถูกประเมินใน subshell ในฐานะผู้ใช้ปัจจุบันซึ่งเป็นเหตุผลว่าทำไมคุณเห็นสิ่งที่คุณทำ


2
นี่เป็นสิ่งที่ผิด sudo ทำงานด้วยสิทธิ์พิเศษของรูท แต่ไม่เป็นรูท
Manfred Moser

@ โมเซอร์ทำไมคำสั่งของเขาถึงสั่งพิมพ์ "รูท"?
Cerin

4
@ManfredMoser: มันทำงานด้วย UID ของ0(ศูนย์) ซึ่งเป็นสิ่งที่ผู้คนเรียกว่า "root" (คุณคงถูกต้องหากsudoขยายขีดความสามารถโดยไม่ต้องเปลี่ยน UID จริง ๆ แต่นั่นไม่ใช่สิ่งที่ทำ)
1686

1
M. Moser อาจจะทำให้ประเด็นเกี่ยวกับ set-UID เพียงการเปลี่ยนID ผู้ใช้ที่มีประสิทธิภาพของกระบวนการซึ่งต้องการให้กระบวนการนั้นไปถึงการเปลี่ยน ID ผู้ใช้จริงเช่นเดียวกับที่sudoทำ แต่จากการอ่านคำตอบของ xyr ดูเหมือนว่าจะไม่ได้เกิดขึ้นจริง
JdeBP

7

subshell ( whoami) จะถูกดำเนินการก่อนตามที่คุณและผลลัพธ์ ( myuser) จะถูกวางลงในsudoคำสั่ง; สิ่งที่เห็นคือsudo echo myuserคิดว่ามันเป็นทางลัดสำหรับ:

tmpvar=`whoami`
sudo echo "$tmpvar"

1

ดูเหมือนว่ามีบางสิ่งที่น่าแปลกใจเกิดขึ้นที่นี่ ...

เห็นได้ชัดว่า backticks ทำในสิ่งที่คนอื่นอธิบายขยายwhoamiก่อนที่จะเรียก 'sudo' และปล่อยให้ backticks off 'root' return ตามที่คาดไว้

แต่มันมีประโยชน์ที่จะเข้าใจสิ่งที่เกิดขึ้นจริงกับ sudo (8) ดังนั้นฉันจึงดูหน้าคนจริง ๆ !

"uid และ gid ที่แท้จริงและมีประสิทธิภาพถูกตั้งค่าให้ตรงกับผู้ใช้เป้าหมาย ... "

ดังนั้นจึงปรากฏว่าพฤติกรรมที่สังเกตไม่เกี่ยวข้องกับความแตกต่างระหว่าง ID ผู้ใช้ที่มีประสิทธิภาพและแท้จริง

นอกจากนี้ยังเป็นตัวอย่างในการทำ "sudo printenv" และเปรียบเทียบกับ "printenv" ซึ่งทำให้ฉันแปลกใจเล็กน้อย มันแสดงให้เห็นว่า [i] มีตัวแปรที่ส่งออก [/ i] บางตัวและอื่น ๆ นั้นไม่ใช่: มันรายงานผู้ใช้ HOME, PATH, PS1, SHELL, TERM และ EDITOR ของผู้ใช้ที่กล่าวอ้าง แต่ไม่ใช่คนอื่น ๆ เช่น MANPATH, CVSROOT, LD_LIBRARY_PATH หรือ ENV ดูเหมือนจะแปลกเล็กน้อยเนื่องจากอาจทำให้โปรแกรมทำงานแตกต่างจากที่ทำในฐานะผู้ใช้ดั้งเดิมหรือในฐานะรูท


0

sudo ช่วยให้คุณสามารถรันคำสั่งใด ๆ ที่มีสิทธิ์ใช้งานรูท แต่ไม่ใช่ในฐานะผู้ใช้รูท เหตุผลนี้มีประโยชน์คือด้วยการตั้งค่านี้หลายคนสามารถมีสิทธิ์รูทการบันทึกทั้งหมดและอื่น ๆ ยังคงระบุว่าใครทำการเปลี่ยนแปลง

การตั้งค่านี้ดีกว่าการแชร์รหัสผ่านรูท เช่นนี้มันได้แทนที่การมีผู้ใช้รูทบนดิสทริบิวชันมากมายรวมถึง Ubuntu

sudo su ในทางกลับกันทำให้คุณเป็นผู้ใช้รูทดังนั้นจึงไม่ควรใช้

ความแตกต่างนี้ยังอธิบายถึงพฤติกรรมที่ถูกต้องของคุณ


6
ไม่สิ่งที่อธิบายถึงพฤติกรรมเป็นเรื่องง่าย ๆ ว่าการทดแทนคำสั่งในเชลล์ทำงานอย่างไร ไม่มีอะไรเกี่ยวข้องกับสิทธิ์
JdeBP

-2

Sudo ให้สิทธิ์ผู้ใช้รูทระดับชั่วคราว (ไม่อนุญาตให้คุณ sudo ตั้งแต่แรก)

ในการเป็นรูทคุณจะต้องเข้าสู่ระบบในฐานะรูทซึ่งถูกบล็อกในอูบุนตูโดยค่าเริ่มต้น

คุณต้องระวังสิ่งนี้ sudo ไม่ใช่รูต หากคุณต้องการแสดงให้เห็นว่า Fred กำลังดำเนินการบางอย่างเป็น sudo, che3d เป็นตัวแปรสภาพแวดล้อม SUDO, SUDO_COMMAND อาจมีประโยชน์มากที่สุด


รูตถูกบล็อคใน Ubuntu หรือไม่ คุณแน่ใจหรือไม่ ฉันรู้ว่ามันหมดกำลังใจ แต่ฉันคิดว่าพวกเขาทำให้ยากสำหรับมือใหม่เล็กน้อยโดยการตั้งค่ารหัสผ่านที่คลุมเครือโดยใช้ UUID ซึ่งสามารถเปลี่ยนแปลงได้โดยใช้วิธีการปกติ
Marty Fried
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.