การเปลี่ยนการอนุญาตของไฟล์ทำหน้าที่เหมือนรูท แต่ไม่ใช่ sudo

ฉันมีปัญหาที่แปลกจริงๆ ฉันมีไฟล์บางไฟล์ในไดเรกทอรีขนาดใหญ่ที่ฉันต้องการให้ทุกคนอ่านได้ ดังนั้นฉันลองทำสิ่งนี้:

sudo find readme* -not -perm -o+r -exec chmod +r {} \;

และรับสิ่งนี้:

sudo: unable to execute /usr/bin/find: Success

ฉันไม่รู้ว่าทำไมมันถึงบอกว่าสำเร็จเพราะสิทธิ์ไม่เปลี่ยนแปลง ฉันยืนยันโดยพิมพ์สิ่งนี้:

find readme* -not -perm -o+r -exec ls -l {} \;

และรับสิ่งที่ต้องการ

-rw------- 1 root root 536871076 Nov 22 14:06 readme_20101122200429
-rw------- 1 root root 536871892 Nov 22 14:08 readme_20101122200642
-rw------- 1 root root 293458128 Nov 22 14:10 readme_20101122200859

ฉันพยายาม:

sudo chmod +r *

และได้รับ:

sudo: unable to execute /bin/chmod: Success

และอีกครั้งความสำเร็จหมายถึงการล้มเหลวจริงๆ ดังนั้นฉันยอมแพ้และเข้าสู่ระบบในฐานะ root และพยายาม:

find readme* -not -perm -o+r -exec chmod +r {} \;

เวลานี้มันทำงาน ทำไม?

แก้ไข: / etc / sudoers ดูเหมือนว่า:

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

##Me
user1   ALL=(ALL)       ALL

linux bash sudo

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

อะไรนะ /etc/sudoers ดูเหมือน?

— Ignacio Vazquez-Abrams

อาจเป็นเพราะ sudo ไม่ได้กลิ้งลงไปใน -exec ส่วนหนึ่งของคำสั่งดังนั้น find ถูกเรียกใช้เป็นราก แต่ chmod ไม่ใช่เหรอ

@Ben Lee: มันเป็นคนแปลกหน้ามากกว่านั้น ดูบรรทัดใหม่ของฉันเกี่ยวกับ sudo chmod +r *

— User1

บางทีเส้นทางของคุณจะเลอะ ชนิด echo $PATH และดูว่ามันถูกต้องหรือไม่ ลองดูสิ which find และ which chmod.

@Ben: ฉันก็คิดเช่นกัน ข้อความข้อผิดพลาด ("ความสำเร็จ") แสดงให้เห็นว่าเส้นทางของปฏิบัติการ ฉันคิดว่ามันดูโอเค

— User1

คำตอบ:

ฉันไม่รู้ว่าคุณใช้เวอร์ชั่นไหน แต่โดยปกติแล้วอาร์กิวเมนต์แรกคือไดเรกทอรีที่จะค้นหาและถ้าคุณต้องการกรองชื่อไฟล์บางตัวคุณต้องใช้อาร์กิวเมนต์ -name ฉันจะเดา

ค้นหา sudo -name 'readme *' -not -perm -o + r -exec chmod + r {} \;

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

คำสั่งที่เขาให้ทำงานได้อย่างสมบูรณ์แบบดีสำหรับฉันด้วย sudo ดังนั้นอาจไม่ใช่กรณี

รสชาติของคำสั่งนี้ใช้งานได้จริง! ฉันมีไฟล์จำนวนมากที่ตรงกับรูปแบบ ฉันคิดว่า * ขยายไฟล์เหล่านั้นทั้งหมดและโอเวอร์โฟลว์บัฟเฟอร์บางส่วน ถ้าฉันทำ -name กับ readme* รูปแบบมันทำงานได้ดี ฉันไม่แน่ใจว่าทำไม นี่คือ RHEL5.5 Sever

— User1

@ User1: มันใช้งานได้ดีที่จะพูดว่า find -name 'readme *' และไม่พบ readme * เพราะในกรณีหลังทุบตีขยาย glob ลงในรายการที่ล้นบัฟเฟอร์คำสั่งและในกรณีที่อดีตพบการขยาย glob ภายใน ไม่มีข้อ จำกัด ดังกล่าว

— phogg

ฉันคิดว่าคุณควรใช้:

sudo sh -c 'find readme* -not -perm -o+r -exec chmod +r {} \;'

สาเหตุนี้ sudo เพื่อเรียกใช้เชลล์ซึ่งตีความอาร์กิวเมนต์เป็น -c เป็นเชลล์สคริปต์ การใช้เครื่องหมายคำพูดเดี่ยวรอบ ๆ มันง่ายที่สุด - ยกเว้นว่าจะมีเครื่องหมายคำพูดเดี่ยวในคำสั่งที่จะดำเนินการ ในกรณีนั้นเครื่องหมายคำพูดเดี่ยวแต่ละคำในคำสั่งจะถูกแทนที่ด้วยอักขระสี่ตัว - '\'': quote, backslash, quote, quote

อย่างไรก็ตามในบริบทนี้ฉันไม่ต้องการรับประกันว่าคุณจะไม่ได้รับ:

sudo: unable to execute /bin/sh: Success

ข้อผิดพลาดแปลก ๆ อาจหมายความว่า exec*() การเรียกฟังก์ชันครอบครัวกลับมา แต่มีค่าเหลือ errno เป็นศูนย์ ไม่ควรเกิดขึ้น - แต่ดูเหมือนว่าจะเป็นเช่นนั้น เกิดอะไรขึ้นกับ:

sudo /bin/ls      # Or /usr/bin/ls if that's correct for your machine

คุณตรวจสอบครั้งสุดท้ายเมื่อวันที่ sudo การติดตั้ง? คุณรีบูตครั้งล่าสุดเมื่อใด ดูเหมือนว่ามีบางอย่างผิดพลาดในทาง sudo คือ (mis) การจัดการคำสั่งสำหรับคุณ

ไดเร็กทอรีที่คุณกำลังทำงานใน NFS ถูกเมาท์หรือไม่? รูทมักจะมีสิทธิ์น้อยที่สุดในไดเรกทอรีดังกล่าว แต่ข้อผิดพลาดควรเป็นของสายพันธุ์ EPERM (ไม่ได้รับอนุญาต) ไม่ใช่สายพันธุ์ 'ความสำเร็จเมื่อล้มเหลว'

— Jonathan Leffler
แหล่งที่มา