Sudo vs root; ความแตกต่างที่เกิดขึ้นจริง?

44

ฉันกำลังทำงานกับสมาชิกสนับสนุนผลิตภัณฑ์และเขายืนยันว่าฉันต้องเป็น root ในการติดตั้งชุดข้อมูลแก้ไขและ sudo นั้นจะไม่ทำงาน เขาไม่ได้ให้เหตุผล แต่ดูเหมือนว่าจะมั่นคงในความเชื่อของเขา เรียกดู Superuser ฉันไม่สามารถระบุสาเหตุที่เป็นไปได้สำหรับกรณีนี้และในการยืนยันเมื่อฉันเรียกใช้:

sudo -l

ฉันเข้าใจ:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

การเข้าถึงจากทีมงาน Linux / Server เพื่อเป็นรูทไม่ใช่กระบวนการเลียนแบบตามที่ฉันเข้าใจดังนั้นฉันจึงต้องการติดตั้งด้วยตนเอง

มีเหตุผลเชิงปฏิบัติใด ๆ ว่าทำไม sudo จะทำงานแตกต่างจากรูทสำหรับการติดตั้งซอฟต์แวร์บนเซิร์ฟเวอร์หรือไม่?

linux sudo root

— ตำรวจท้องถิ่น
แหล่งที่มา

2

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

— Garrett

1

คำนึงถึงสิ่งแวดล้อมและคำสั่งย่อย ฉันคิดว่า Hastur ทำงานได้ดีกับสภาพแวดล้อมและ Jayen ทำงานหนักด้วยคำสั่งย่อยการวางท่อและการเปลี่ยนเส้นทาง

— jww

2

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

— jww

34

มันยิ่งขึ้นอยู่กับวิธีที่คุณเรียกโปรแกรมของคุณด้วยหรือsudo เช่นในระบบที่ฉันเป็นในขณะนี้:su

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1]

โดยที่ [1] = / usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / sbin: / bin
Env = ตัวแปรสภาพแวดล้อมถูกรีเซ็ต 1 และ 5 นำมาจาก $ USER ใน 2,3,4

ดังนั้นสคริปต์หรือโปรแกรมที่จะเปิดตัวพร้อมกับตัวเลือกที่แตกต่างกันสามารถมองเห็นที่แตกต่างกัน$PATH, $HOMEเปลือกของมันสามารถอ่านที่แตกต่างกัน.bashrc, .profileและตัวแปรสภาพแวดล้อม $HOMEมันอ่านไฟล์ที่เกี่ยวข้องกับ ผู้ใช้แต่ละคนสามารถปรับเปลี่ยนสภาพแวดล้อมของเขาในวิธีที่แตกต่างกัน (ตัวแปร$PATH,, .bashrc, .profile, .bash_profile, alias ... ) โดยเฉพาะอย่างยิ่งผู้ใช้สามารถมีลำดับที่แตกต่างกันของไดเรกทอรีในของเขา$PATHและเป็นผลให้สคริปต์สามารถดำเนินการคำสั่งเช่นใน/home/$USER/binแทนจากนั้นหนึ่งในเส้นทางที่คาดหวังจากราก

คุณสามารถเรียกใช้โปรแกรมที่อยู่ภายใต้sudo -iตามที่คุณได้ลงทะเบียนเป็นรากที่มีsu -แต่คุณสามารถมีพฤติกรรมที่แตกต่างกันถ้าคุณใช้มันด้วยหรือsudo MyCommandsu -c MyCommand

จากman su:

ในส่วนคำอธิบาย: สภาพแวดล้อมในปัจจุบันมีการส่งผ่านไปยังเปลือกใหม่
ค่าของ$ PATH จะถูกรีเซ็ตเป็น / bin: / usr / bin สำหรับผู้ใช้ปกติหรือ / sbin: / bin: / usr / sbin: / usr / bin สำหรับ superuser
...
ในส่วนของตัวเลือก:
- , -l , --login
จัดเตรียมสภาพแวดล้อมคล้ายกับสิ่งที่ผู้ใช้คาดหวังว่าจะมีผู้ใช้เข้าสู่ระบบโดยตรง

จากมนุษย์ sudo

-i , --login
รันเชลล์ที่ระบุโดยรายการฐานข้อมูลรหัสผ่านของผู้ใช้เป้าหมายเป็นเชลล์ล็อกอิน ซึ่งหมายความว่าไฟล์ทรัพยากรเฉพาะการเข้าสู่ระบบเช่น. profile หรือ .login จะถูกอ่านโดยเชลล์ หากระบุคำสั่งคำสั่งจะถูกส่งไปยังเชลล์เพื่อดำเนินการผ่านตัวเลือกเชลล์ของ -c หากไม่ได้ระบุคำสั่งเชลล์เชิงโต้ตอบจะถูกดำเนินการ sudoพยายามเปลี่ยนเป็นโฮมไดเร็กทอรีของผู้ใช้นั้นก่อนรันเชลล์ คำสั่งทำงานกับสภาพแวดล้อมที่คล้ายกับที่ผู้ใช้จะได้รับในการเข้าสู่ระบบ ส่วนคำสั่งสภาพแวดล้อมในเอกสารคู่มือ sudoers (5) วิธีที่ตัวเลือก -i ส่งผลกระทบต่อสภาพแวดล้อมที่คำสั่งจะทำงานเมื่อมีการใช้นโยบาย sudoers

— แฮสเธอร์
แหล่งที่มา

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

— fixer1234

23

หากคุณsudoเข้าถึงได้เต็มที่คุณจะสามารถrootใช้sudo su -งานได้ดังนั้นจุดรักษาความปลอดภัยก็จะถูกคำนวณ

อันที่จริงมีวิธีที่จะแยกแยะความแตกต่างระหว่างโปรแกรมที่ทำงานในขณะrootที่โปรแกรมทำงานภายใต้การsudoใช้getuidvs geteuid- แต่นี่เป็นเคล็ดลับที่ได้วางแผนไว้ ทำไมระบบแพทช์ถึงทำเช่นนั้น

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

5

พูดถึงsu -เขาอาจต้องการใช้sudo -iเพื่อให้เขามีสภาพแวดล้อมเดียวกันกับเมื่อเข้าสู่ระบบโดยตรง

— Cristian Ciupitu

2

หากคุณทำงานด้วยเช่นsudo myscriptคุณจะเก็บ $ PATH และตัวแปรสภาพแวดล้อมจากเชลล์ที่คุณอยู่ หากคุณทำงานกับsudo -i myscriptคุณทำงานราวกับว่าคุณเข้าสู่ระบบในฐานะ root ดูคำตอบด้วย_zoo

— Hastur

1

ฉันคิดว่าสิ่งสำคัญคือต้องชี้ให้เห็นว่าตัวแปรสภาพแวดล้อมอาจไม่สามารถตั้งค่าได้เหมือนกันภายใต้sudoการเข้าสู่ระบบในฐานะ root

— secretformula

1

@dmanexe: sudo ไม่ได้หมายถึง superuser do มันคือ "switch user do" su และ sudo สามารถใช้เพื่อสลับไปยังผู้ใช้ใด ๆ แทนที่จะเป็น superuser นอกจากนี้ยังไม่มีอะไรหลอกเกี่ยวกับ sudo คุณจะได้รับรูทจริงเมื่อใช้ sudo ไม่ได้แกล้งทำอะไร โปรดทราบว่าความมหัศจรรย์ของ sudo มาจากสิทธิ์บิต setuid

— โกหก, นอน

2

SDS, @CharlesDuffy: ความคิดที่ว่า sudo su และสาเหตุgeteuid()และgetuid()จะแตกต่างจากอีกคนหนึ่งเป็นตำนาน su และ sudo เปลี่ยนทั้ง ID ผู้ใช้จริงและมีประสิทธิภาพเป็นของผู้ใช้เป้าหมายก่อนที่จะรันคำสั่งหรือเชลล์ที่ระบุยกเว้นในสถานการณ์ที่ผิดปกติมากซึ่งคุณได้กำหนดค่าไว้อย่างชัดเจน คุณสามารถตรวจสอบนี้ (sudo) โดยการเรียกใช้sudo id -uและsudo id -ru(ทั้งแสดง 0), อ่านsudo (8) (ภายใต้คำสั่งการดำเนินการ ) หรือการเขียนโปรแกรมการทดสอบ

7

มีความแตกต่างเล็กน้อยหากคุณได้รับเชลล์รูทตามที่ @Hastur ชี้ให้เห็น

หากคุณไม่ได้รับรูทเชลล์คุณก็จะมีความแตกต่างมากขึ้น สมาชิกสนับสนุนอาจมีประสบการณ์พยายามทำสิ่งต่าง ๆ เช่นsudo patch -p0 < /root/patch.fileที่patchทำงานเหมือนรูท แต่<(การไพพ์จากไฟล์) ไม่ใช่

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

1

ถูกต้อง: มุมมองที่ใช้งานได้จริงมักจะให้คำแนะนำที่ยากต่อการมองเห็นจากหน้าคู่มือเท่านั้น ที่จะเอาชนะสถานการณ์ที่คล้ายกันคุณถูกบังคับทำออกกำลังกายมากขึ้น [:-)] sudo /bin/bash -c "./patch -p0 < /root/patch"เช่นการเขียนสิ่งที่ต้องการ >แม้จะละเอียดอ่อนมากขึ้นเป็นกรณีที่เมื่อคุณใช้การเปลี่ยนเส้นทางในการสร้างไฟล์ ในวิธีแรกคุณจะสร้างไฟล์ที่เป็นของผู้ใช้เฉพาะในกรณีที่คุณมีสิทธิ์พอที่จะเขียนในไดเรกทอรีสุดท้าย ในทางที่หลังคุณจะสร้างไฟล์ที่เป็นของราก ... ด้านมืดของระบบปฏิบัติการยูนิกซ์ ;-)

— แฮสเธอร์

1

ฉันเชื่อว่าเมื่อใช้การเข้าถึง sudo ไฟล์บันทึกจะถูกสร้างขึ้น แต่เมื่อทำงานโดยตรงผ่านการเข้าถึงรูทจะไม่มี

— แอชลีย์เรดแมน BSc
แหล่งที่มา

0

ขึ้นอยู่กับว่าเม็ดเล็กละเอียดที่คุณต้องการให้รูทเข้าถึงนั้นเป็นอย่างไร หากคุณมีผู้ใช้หลายคนที่ทำงานต่าง ๆ บนระบบ sudo จะเหมาะกว่า ตัวอย่างหนึ่งที่ฉันใช้บ่อย ๆ คือต้องรีสตาร์ทแอปพลิเคชันหรือฐานข้อมูล การรักษาความปลอดภัยจะทำดีที่สุดอย่างน้อยสิทธิพิเศษ ฉันใช้กลุ่มและอนุญาตเฉพาะกลุ่มเหล่านั้นเพื่อดำเนินการอย่างชัดเจน หนังสือที่ดีที่อธิบายกระบวนการนี้คือ "Sudo Mastery: การควบคุมการเข้าถึงของผู้ใช้สำหรับคนจริงๆ" จริงๆแล้วมันเป็นหนังสือที่ดีเกี่ยวกับ sudo โดยทั่วไป ...

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