ฉันจะรู้ได้อย่างไรว่าฉันได้รับอนุญาตให้เรียกใช้คำสั่งเฉพาะ?


18

มีวิธีใดที่จะระบุว่าฉันในฐานะผู้ใช้ทั่วไปมีสิทธิ์ออกคำสั่งหรือไม่

ตัวอย่างเช่น; ฉันต้องการตรวจสอบว่าฉันมีสิทธิ์ออกคำสั่งปิดเครื่องก่อนที่ฉันจะออกจริงหรือไม่

คล้ายคำสั่งต่อไปนี้

-> doIhaveRightToIssue shutdown
-> Yes/No

4
วิธีที่ตรงไปตรงมาคือการลอง (ไม่sudo) และค้นหา คำสั่งโหมดข้อความอาจต้องและคำสั่งกราฟิกอาจต้องsudo นอกจากนี้คุณยังสามารถตรวจสอบที่คำสั่งจะถูกติดตั้งกับgksudo which commandหากใน/sbinหรือ/usr/sbin- คุณสามารถคาดหวังว่าความต้องการของคำสั่งหรือsudo gksudo
sudodus

คำตอบ:


26

gzipกรณีที่ง่ายที่สุดคือที่ของเหมือนไบนารี ก่อนอื่นเราหาไฟล์ปฏิบัติการ:

$ which gzip
/bin/gzip

จากนั้นเราจะดูคุณสมบัติของไฟล์นี้:

$ ls -l /bin/gzip
-rwxr-xr-x 1 root root 98240 oct 27  2014 /bin/gzip

สามตัวนั้นบอกเราว่าไฟล์นั้นอาจถูกเรียกใช้โดยเจ้าของ (ตัวแรกroot) หรือทุกคนในกลุ่มroot(วินาทีroot) และคนอื่น ๆ ตามลำดับ ดังนั้นผู้ใช้ของคุณได้รับอนุญาตให้รันโปรแกรม

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

จากนั้นมีกรณีพิเศษเช่นshutdown- นี่คือการเชื่อมโยงสัญลักษณ์ไปยังยูทิลิตี้หลักที่เรียกว่าsystemctlซึ่งมีกลไกของตัวเองเพื่อตรวจสอบว่าคุณได้รับอนุญาตให้โทรหรือไม่และขอรหัสผ่าน sudo ของคุณหากไม่เช่นนั้น .

(เกี่ยวกับwhichคำสั่ง: นี้ตั้งอยู่ executables ใน $ PATH ของคุณที่คุณได้รับอนุญาตให้ดำเนินการและบอกคุณว่าคุณใช้ที่ใดถ้าคุณมีมากกว่าหนึ่งที่มีชื่อเดียวกันใน $ PATH มันไม่ได้ค้นหาเพียงปฏิบัติการใด ๆ ฉัน ใช้ที่นี่เป็นตัวอย่างของตำแหน่งที่จะค้นหาการอนุญาตความจริงที่whichพบว่าการปฏิบัติการนั้นบ่งชี้ว่าคุณได้รับอนุญาตให้เรียกใช้งานมัน)


คำตอบที่กระชับมาก (+1) ตัวอย่างเช่นเป็นไปได้ที่จะจำลองผลลัพธ์ของ apt-get install ด้วยแฟล็ก -s (sudo apt-get install -s htop) ฉันคิดว่าถ้าไม่มีวิธีที่จะเรียนรู้การอนุญาตของคำสั่งก่อนหนึ่งปัญหามีอย่างน้อยสิ่งเช่น "จำลอง"
แบร์นฮาร์ดคอล

แน่นอนว่ามียูทิลิตี้ที่ให้การตั้งค่าสถานะ "dry-run" หรือ "จำลอง" ที่คุณสามารถใช้ได้
Jos

4
whichคำสั่งควรจะเพียงพอสำหรับไฟล์เหล่านั้นที่อยู่ในหนึ่งในไดเรกทอรีที่เพิ่มเข้าไปใน$PATHตัวแปร ตัวอย่างเช่นการทำsudo chmod 700 /bin/nanoหรือsudo chmod 744 nanoทำให้whichไม่มีผลลัพธ์ สำหรับสคริปต์ในเครื่องที่อยู่ที่อื่นนอกเหนือจากหนึ่งในPATHไดเรกทอรีls -lหรือการstatโทรจะทำการหลอกลวง คำตอบที่ดี แต่โปรดเพิ่มข้อมูลนี้ในโพสต์ของคุณ
Sergiy Kolodyazhnyy

ออกไปจากสิ่งที่ Serg พูดใช้บางอย่างstat -c '%a' /bin/gzipที่755เป็นตัวอย่าง
AT

21

ด้วยsudo:

$ sudo -l shutdown
/sbin/shutdown

หากฉันไม่ได้รับอนุญาตsudoจะบ่นแทนการแสดงคำสั่ง

ด้วย polkit คุณตรวจสอบการกระทำที่คุณต้องการเรียกใช้:

$ pkcheck --action-id org.freedesktop.login1.power-off --process $$ -u --enable-internal-agent && echo yes
polkit\56temporary_authorization_id=tmpauthz1
yes

การค้นหาการกระทำที่เกี่ยวข้องเป็นคำถามที่แตกต่าง


ปัญหากับ sudo คือฉันไม่ได้ sudoer ในระบบ ด้วยเหตุนี้ฉันจึงพยายามระวังก่อนที่ฉันจะออกคำสั่งจริงๆ
Bernhard Colby

4
@BernhardColby คุณสามารถทำงานได้อย่างปลอดภัยsudo -lแม้ว่าคุณจะไม่ใช่ sudoer - นั่นเป็นจุดรวมของ-l- ที่จะบอกคุณว่าคุณสามารถเรียกใช้คำสั่งด้วย sudo ได้หรือไม่
muru

ขอบคุณ (+1) ฉันไม่รู้ ฉันจะลองวิธีแก้ปัญหาของคุณทันทีที่ฉันได้รับพีซีของฉัน
Bernhard Colby

8

คุณสามารถใช้ได้:

test -x $(command -v shutdown) && echo yes || echo no

command -v shutdownส่งคืนพา ธ ไปที่shutdownคำสั่ง test -xตรวจสอบว่าเส้นทางนั้นสามารถทำงานได้กับคุณหรือไม่

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


แล้วยังalias shutdown="shutdown now"ไง
Dmitry Grigoryev

เพื่อหลีกเลี่ยงปัญหากับนามแฝงหนึ่งสามารถใช้หรือ$(which shutdown) $(shopt -u expand_aliases && command -v shutdown)ปัญหานี้จะปรากฏขึ้นในโหมดโต้ตอบเท่านั้น
David Foerster

5

ในบางครั้งมันอาจจะยากสักหน่อย ...

ก่อนอื่นดูที่การอนุญาตด้วยls -l...

 คำสั่งกลุ่มผู้ใช้ owngrpotr
-rwxr-xr-x root bin vim

หากแฝดสาม / สามมีx ("สามารถเรียกใช้งาน") ได้ผู้อื่น - และนั่นหมายความว่าคุณ - สามารถดำเนินการได้ ... หากเป็นเชลล์สคริปต์หรืออะไรทำนองนั้นผู้อื่นจะต้องr (" สามารถอ่าน ") ได้เช่นกัน

ถ้าคนอื่น ๆไม่ได้รับการดำเนินการอนุญาต แต่กลุ่ม (แฝดสอง) ไม่แล้วคุณสามารถดำเนินการได้ถ้าคุณเป็นสมาชิกของกลุ่ม - ในตัวอย่างมากกว่าถัง ตัวอย่างเช่นกลุ่มล้อ -มักจะใช้ในการ จำกัด ผู้ที่อาจทำงานsuดังนั้นผู้ใช้ที่อยู่ในกลุ่มนี้เท่านั้นที่สามารถดำเนินการได้เลย อีกตัวอย่างหนึ่งคือการสร้างกลุ่มเพื่อพัฒนา ers และ จำกัด การดำเนินการของคอมไพเลอร์ C และเครื่องมือดังกล่าวให้กับกลุ่มนี้

หากมีการต่อท้าย+หลังจากแฝดสุดท้ายนั่นหมายความว่ามีการใช้ AccessControllLists ซึ่งอาจเพิ่มสิทธิ์การดำเนินการให้กับผู้ใช้และกลุ่มเพิ่มเติม

+++

แม้ว่าคุณจะสามารถดำเนินการคำสั่งได้ แต่คำสั่งอาจขึ้นอยู่กับการเข้าถึงไฟล์ไดเรกทอรีและ / หรืออุปกรณ์ที่คุณไม่สามารถเข้าถึงได้ - สิ่งนี้อาจ จำกัด สิ่งที่คุณจะทำได้ (คุณอาจไม่สามารถทำได้ ทำอะไรก็ได้)

ในที่สุดแม้ว่าคุณอาจได้รับอนุญาตให้ดำเนินการคำสั่งคำสั่งนั้นอาจตรวจสอบตัวตนของคุณและปฏิเสธที่จะให้คุณใช้งานได้เว้นแต่คุณจะอยู่ในไฟล์ config หรือเป็นผู้ใช้บางคน (เช่นรูท ) ตัวอย่างเช่นmountคำสั่งจะอนุญาตให้รูทเพื่อเมานต์อุปกรณ์ใด ๆ - ผู้ใช้ปกติจะได้รับอนุญาตเท่านั้นที่จะเมานต์อุปกรณ์ที่ระบุไว้ใน / etc / fstab ... ซึ่งอาจไม่มี หากคุณไม่รูทและพยายามเมานต์อะไรmountก็จะบ่นและปฏิเสธที่จะเมานต์อุปกรณ์ อีกตัวอย่างคือsudoซึ่งจะทำงานให้กับทุกคน แต่เฉพาะผู้ใช้ที่มีรายชื่ออยู่ใน / etc / sudoers เท่านั้นที่จะได้รับอนุญาตให้เรียกใช้สิ่งต่าง ๆ ในฐานะรู


3

การใช้which, type, commandฯลฯ เป็นวิธีการแก้ปัญหาในทางปฏิบัติที่จะทำงานใน 99% ของกรณี แต่จะเป็น 100% $PATHว่าคุณจะต้องตรวจสอบด้วยตนเองทุกไดเรกทอรีที่ปฏิบัติการได้ระบุไว้ในของคุณ เชลล์จำนวนมาก (รวมถึงbash) จะนำหน้าคำสั่งของคุณด้วย entres จาก$PATHและพยายามเรียกใช้ไฟล์เหล่านั้นซ้ำ ๆ จนกว่าจะสำเร็จ เนื่องจากwhichไม่สามารถดำเนินการคำสั่งได้จริงจึงเป็นไปไม่ได้ที่จะคาดเดาว่าไฟล์ใดที่เชลล์ของคุณจะเลือก

ตัวอย่างเช่นสมมติว่าฉันมีPATH=/opt/arm/bin:/binทั้งไดเรกทอรีที่มีไฟล์ปฏิบัติการ แต่สำหรับสถาปัตยกรรมที่แตกต่างกัน วิ่งwhich ddจะกลับมา/opt/arm/bin/dd(สมมติว่าฉันมีสิทธิ์ในการดำเนินการ) เนื่องจากรายการนั้นมาก่อน อย่างไรก็ตามเมื่อฉันทำงานddในเชลล์ของฉัน/bin/ddจะถูกประหารชีวิตเพราะ/opt/arm/bin/ddจะล้มเหลวในการทำงาน สถานการณ์เดียวกันอาจเกิดขึ้นในกรณีของไบนารีที่เสียหาย libs ที่ขาดหายไปเป็นต้นในตอนท้ายไม่มีวิธีที่แน่นอนที่จะทราบว่าคุณจะสามารถดำเนินการคำสั่งได้หรือไม่นอกเหนือจากการลอง

อีกแง่มุมหนึ่งคือสิ่งที่คุณพิจารณาว่า "มีสิทธิ์" ในฐานะผู้ใช้ผมไม่ได้รับอนุญาตให้ทำงานแต่ไม่rm ~/file rm /root/fileอีกครั้งไม่มีวิธีทั่วไปที่จะรู้ว่าหากไม่มีการตรวจสอบด้วยตนเองหรือออกคำสั่งและสังเกตผลลัพธ์

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.