ควรสคริปต์ที่ต้องใช้ sudo ล้มเหลวหากไม่มีหรือใช้ sudo และพรอมต์?


26

ฉันมีสคริปต์ที่ให้การควบคุมความสว่างแบ็คไลท์ของฉันอย่างละเอียดและต้องsudoดำเนินการ เป็นหลักนี้:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | tee $backlight

~/bin/backlight-adjustและชีวิตที่ สคริปต์ต้องการsudoสิทธิ์เนื่องจากtee $backlightกำลังเขียนไปยังตำแหน่งที่มีสิทธิ์ sudoดังนั้นมันจะล้มเหลวถ้ามันไม่ได้ทำงานด้วย

วิธีการนี้มีปัญหาเพราะฉันไม่สามารถวิ่งsudo backlight-adjustได้เพราะ~/binไม่ได้อยู่$PATHในsudoสภาพแวดล้อม แต่ในสภาพแวดล้อมของฉันเท่านั้น ดังนั้นฉันต้องวิ่งsudo env "PATH=$PATH" backlight-adjustหรืออะไรทำนองนั้น

หรือฉันอาจจะเขียนมันแบบนี้

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | sudo tee $backlight

และแจ้งรหัสผ่านให้ฉัน

วิธีที่สองใช้งานได้ดีกว่าสำหรับฉันเพราะฉันไม่ต้องจำให้พิมพ์ sudo; มันจะทำให้ฉัน และฉันสามารถรักษา$PATHเหมือนเดิม โดยรวมแล้วรู้สึกสะดวกกว่า แต่มีเหตุผลใดที่ฉันไม่ควรทำอย่างที่สอง?

(ฉันใช้ Xubuntu 14.04 และเชลล์ของฉันคือ GNU ทุบตี 4.2.45 ถ้านั่นสร้างความแตกต่าง)


ขอบคุณสำหรับการแก้ไข ฉันใช้ Debian (LMDE) ที่ได้รับการแก้ไขแล้วและค่าเริ่มต้นของฉันsudoจะเก็บ$PATHตามจริงดังนั้นฉันจึงไม่มีปัญหานี้
terdon

คำตอบ:


27

โดยส่วนตัวแล้วฉันจะใช้วิธีการอื่น สร้างชื่อแทนสคริปต์ของคุณ เพิ่มบรรทัดนี้ในของคุณ~/.bashrc(หรือเทียบเท่าในเปลือกหอยอื่น ๆ )

alias backlight-adjust='sudo ~/bin/backlight-adjust'

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


ดูเหมือนว่าเป็นแนวทางที่สมเหตุสมผลมากและวิธีนี้มีผลกระทบต่อระบบอื่น ๆ น้อยที่สุด +1
John Feminella

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

@ KyleStrand ไม่มีพวกเขาจะไม่ คำสั่งที่สคริปต์เรียกนั้นจะบ่นว่าไม่สามารถเข้าถึงได้
terdon

@terdon ฉันรู้ว่าฉันอาจจะชัดเจนกว่านี้เล็กน้อย แต่น่าจะเป็นที่คุณรู้ว่าสิ่งที่ฉันหมายถึง: ผู้รับสคริปต์จะประสบปัญหาเดียวกันกับที่ผู้เขียนสคริปต์ต้องเผชิญในขั้นต้นและในฐานะผู้เขียนบทที่มีสติ แบ่งปันโซลูชันส่วนบุคคลของพวกเขาให้กับปัญหาการใช้งานนี้โดยเฉพาะ
Kyle Strand

@ KyleStrand ใช่ แต่ไม่มีปัญหาปัญหาเดียวที่ OP มีคือเขาไม่ต้องการที่จะ "จำได้ว่าต้องพิมพ์ sudo" นอกจากนั้นสคริปต์จะสามารถพกพาได้อย่างสมบูรณ์แบบ ประเด็นของฉันคือนามแฝงเป็นตัวเลือกที่สมบูรณ์และไม่ได้แก้ปัญหาอะไรเลยมันแค่ทำให้ใช้งานได้ง่ายขึ้น
terdon

7

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

แต่ ... ทำไมไม่เพิ่ม

chgrp  one-of-your-groups-here /sys/class/backlight/acpi_video0/brightness     
chmod g+w /sys/class/backlight/acpi_video0/brightness 

ในของคุณ/etc/rc.localและลืมเกี่ยวกับsudo?

(ใน Ubuntu ถ้าคุณสามารถใช้sudoคุณอยู่ในกลุ่มsudoดังนั้นคุณสามารถใช้chgrp sudo /sys...และมีความสุขได้)


3

หรือคุณสามารถเพิ่ม

Defaults        env_keep +="PATH"

ไปยัง/etc/sudoersไฟล์ของคุณ


2

คุณระบุsudo backlight-adjustment เนื่องจาก ~ / bin ไม่ได้อยู่ใน $ PATH ในสภาพแวดล้อม sudo

เหตุใดจึงต้องพึ่งพาสิ่งนั้น ฉันคิดว่าคุณควรเปลี่ยนบรรทัด/home/user/bin/backlight-adjustนั้นและมันจะใช้ได้

แต่ฉันชอบโซลูชั่นของ Terdon ที่ใช้นามแฝงด้วย หรือคุณสามารถวางสคริปต์ของคุณ/usr/bin/และมันจะพร้อมใช้งานสำหรับผู้ใช้ทุกคน (รวมถึง root)


ใช่ แต่มันน่ารำคาญที่จะทำเช่นนั้น มิฉะนั้นสิ่งที่เป็นจุดของการวางไว้ใน $ PATH ของฉันในสถานที่แรก? นอกจากนี้ฉันชอบที่จะมี~/binเพราะมันอยู่ภายใต้ที่เก็บ dotfiles ของบ้านของฉันดังนั้นมันจึงอยู่ในการควบคุมเวอร์ชัน
John Feminella

@JohnFeminella โดยวิธีการที่ไม่มีเหตุผลที่จะเปลี่ยนเส้นทางเพียงแค่ใช้-Eธงเพื่อรักษาสภาพแวดล้อม:sudo -E command
terdon

@terdon นั่นใช้ไม่ได้กับ Debian; มันถูกแทนที่ด้วยเหตุผลด้านความปลอดภัย คุณต้องผ่านตัวแปรสภาพแวดล้อมอย่างชัดเจนตามที่ฉันพูดถึงในคำถามของฉัน ( sudo env "PATH=$PATH" ...)
John Feminella

1

ไม่สามารถให้กฎทั่วไป ... หากสคริปต์ / โปรแกรมได้รับการออกแบบเพื่อทำการกำหนดค่าใหม่ (เช่นเครื่องพิมพ์) และถูกเรียกใช้โดยผู้ใช้ทั่วไปจะต้องดำเนินการ มิฉะนั้นฉันจะปล่อยให้อยู่คนเดียวดีพอ: หากผู้ใช้ปกติเรียกใช้มันล้มเหลว (อาจเป็นผลมาจากการตรวจสอบที่ชัดเจนหรือเพียงเพราะไม่ได้รับอนุญาตให้ทำอะไร)

ยกระดับสิทธิ์ควรแจกจ่ายเท่าที่จำเป็นถ้าทั้งหมด การเปลี่ยนไปใช้สิทธิ์ที่สูงกว่านั้นเป็นเรื่องยากและควรทิ้งไว้กับผู้เชี่ยวชาญ (เช่นsudo(1))


0

ฉันใช้สิ่งที่ชอบ${SUDO}ในสคริปต์ของฉันเป็นการส่วนตัวเพื่อให้ผู้โทรสามารถตั้งค่าได้ถ้าจำเป็นหรือ${SUDO:-sudo}ใช้เป็นค่าเริ่มต้น

ในกรณีเฉพาะของคุณฉันมีคำตอบที่ได้รับการยอมรับ


-1

วางสคริปต์ (โดยไม่มีsudo) ในตำแหน่งที่เหมาะสมกับผู้ใช้เช่น/binจากนั้นทำสิ่งนี้:

sudo chown root /bin/backlight-adjust
sudo chmod 4755 /bin/backlight-adjust

สิ่งนี้ทำงานได้โดยการตั้งค่าสถานะ setuid ซึ่งหมายความว่ามันจะทำงานในฐานะเจ้าของไฟล์เสมอ สำหรับรายละเอียดโปรดอ่านhttp://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/ ฉันไม่รู้จริงๆทั้งหมดเกี่ยวกับวิธีการทำงานนี้ฉันเพิ่งพบว่า googling ตามสิ่งที่ฉันคิดว่าฉันอ่านไม่กี่ปีที่ผ่านมา


1
เชลล์สคริปต์ไม่สามารถตั้งค่าได้อีกต่อไปขอบคุณพระเจ้า ... นี่คือคำตอบที่ชั่วร้ายที่สุด ความปลอดภัยโดยเฉพาะอย่างยิ่ง
mirabilos

@mirabilos เป็นอันตรายเฉพาะในกรณีที่กลุ่มหรือธงเขียนทั่วไปอยู่บน ความเสี่ยงกับ setuid คือทุกคนที่มีสิทธิ์ในการเขียนสำหรับไฟล์สามารถเรียกใช้สิ่งที่พวกเขาชอบราวกับว่าพวกเขาเป็นผู้ใช้และดังนั้นจึงเป็นสิทธิ์การเขียนเหล่านี้ที่ต้องได้รับการคุ้มครอง 4755หมายถึงการดำเนินการในฐานะเจ้าของเสมอเจ้าของสามารถอ่านเขียนและดำเนินการกลุ่มสามารถอ่านและดำเนินการและผู้ใช้สามารถอ่านและดำเนินการซึ่งเป็นระดับสิทธิ์มาตรฐานสำหรับสิ่งที่ผู้ใช้ควรได้รับอนุญาตให้ทำด้วยสิทธิ์ราก
AJMansfield

@ mirabilos และความคิดที่ว่าเชลล์สคริปต์กับ setuid นั้นมีช่องโหว่มากกว่าไบนารีที่มี setuid นั้นเป็นเพียงความโง่เขลา ไบนารีไม่ได้รับการยกเว้นจากการใช้ประโยชน์จาก ptrace เช่นกันซึ่งเป็นช่องโหว่หลักที่ใช้ประโยชน์จาก setuid
AJMansfield

2
ระบบปฏิบัติการ Unix like like ปัจจุบันทั้งหมดห้ามใช้สคริปต์ setuid นี่เป็นเพียงความจริง ถามเหตุผลด้วยตัวเองถ้าคุณไม่เชื่อฉัน เริ่มด้วย OpenBSD
mirabilos
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.