เรียกใช้. /script.sh เทียบกับ bash script.sh - สิทธิ์ถูกปฏิเสธ

เมื่อฉันพยายามวิ่ง./script.shฉันได้Permission deniedแต่เมื่อฉันวิ่งbash script.shทุกอย่างก็โอเค

ฉันทำผิดอะไร?

สิทธิ์ POSIX ไม่ถูกต้อง

script.shมันหมายความว่าคุณไม่ได้มีการตั้งค่าผู้ได้รับอนุญาตบิตสำหรับ เมื่อใช้คุณต้องการเพียงสิทธิ์ในการอ่านสำหรับbash script.sh script.shดูความแตกต่างระหว่างการเรียกใช้ "bash script.sh" และ "./script.sh" คืออะไร สำหรับข้อมูลเพิ่มเติม

ls -l script.shคุณสามารถตรวจสอบโดยการเรียกใช้

คุณอาจไม่จำเป็นต้องเริ่มกระบวนการทุบตีใหม่ ในหลายกรณีคุณสามารถเรียกใช้source script.shหรือ. script.shเรียกใช้คำสั่งสคริปต์ในเชลล์แบบโต้ตอบปัจจุบันของคุณได้ คุณอาจต้องการเริ่มต้นกระบวนการ Bash ใหม่หากสคริปต์เปลี่ยนไดเรกทอรีปัจจุบันหรือปรับเปลี่ยนสภาพแวดล้อมของกระบวนการปัจจุบัน

รายการควบคุมการเข้าถึง

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

$ ls -l t.sh
-rwxrwxrwx+ 1 root root 22 May 14 15:30 t.sh

อย่างไรก็ตามการพยายามเรียกใช้ผลลัพธ์ไฟล์ใน:

$ ./t.sh
bash: ./t.sh: Permission denied

getfaclคำสั่งแสดงให้เห็นเหตุผลว่าทำไม:

$ getfacl t.sh
# file: t.sh
# owner: root
# group: root
user::rwx
group::r--
group:domain\040users:rw-
mask::rwx
other::rwx

ในกรณีนี้กลุ่มหลักของฉันคือdomain usersการที่ได้มีการดำเนินการอนุญาตเพิกถอนโดยการ จำกัด ACL sudo setfacl -m 'g:domain\040users:rw-' t.shกับ ข้อ จำกัด นี้สามารถยกได้โดยคำสั่งอย่างใดอย่างหนึ่งต่อไปนี้:

sudo setfacl -m 'g:domain\040users:rwx' t.sh
sudo setfacl -b t.sh

ดู:

• รายการควบคุมการเข้าถึง Arch Linux Wiki
• การใช้ ACL กับ Fedora Core 2

ระบบไฟล์ถูกเมาท์พร้อมตัวเลือก noexec

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

สิ่งนี้สามารถตรวจสอบได้โดยการรันmountเพื่อแสดงรายการระบบไฟล์ที่เมาท์ทั้งหมด; ตัวเลือกการเมาท์จะแสดงรายการในวงเล็บในรายการที่สอดคล้องกับระบบไฟล์เช่น

/dev/sda3 on /tmp type ext3 (rw,noexec)

คุณสามารถย้ายสคริปต์ไปยังระบบไฟล์ที่เมาท์อื่นหรือติดตั้งระบบไฟล์ใหม่เพื่อให้สามารถดำเนินการได้:

sudo mount -o remount,exec /dev/sda3 /tmp

หมายเหตุ: ฉันใช้/tmpเป็นตัวอย่างที่นี่เนื่องจากมีเหตุผลด้านความปลอดภัยที่ดีสำหรับการ/tmpติดตั้งกับnoexec,nodev,nosuidชุดตัวเลือก

ลอง

chmod 755 script.sh

สิ่งนี้จะทำให้ไฟล์ประมวลผลได้ จากนั้นลอง

./script.sh

หวังว่ามันจะใช้ได้

ใน win7 ของฉันกับผู้ดูแลระบบที่ใช้ cmd; ฉันมีไฟล์. sh ที่เชื่อมโยงกับ cygwin64 / bin / bash แต่ถูกบล็อกโดย cmd ไม่มีคำแนะนำข้างต้นที่ช่วย (chmod, setfacl, mount)

วิธีแก้ปัญหาด้านล่างใช้งานได้มันเป็น sledge-hammer acl-fixer ของผู้ดูแลระบบเมื่อใดก็ตามที่โฟลเดอร์ / ไฟล์ไม่สามารถเข้าถึงผู้ดูแลระบบบน win7 ซึ่งมักจะเป็น):

  Start > run cmd as Admin
  c:\> script.sh
    Access is denied.

  cmd> chmod 0777 script.sh c:\cygwin64\bin\bash.exe
  cmd> script.sh
    Access is denied.

  > assoc .sh
  .sh=bash

  > ftype bash
  bash=C:\cygwin64\bin\bash.exe -- "%1" %*

  > bash
  $ FILE=c:/cygwin64/bin/bash.exe
  $ FILE=${FILE////\\} # s,/,\,g

  # Compare these permissions using accesschk by Mark Russinovich 2015
  $ accesschk.exe -lq  $FILE 
  $ accesschk.exe -lq c:/windows/system32/cmd.exe
  # [large output not shown]

  # === Solution: Change windows acl for bash ===
  $ takeown /F $FILE /A > /dev/null
  $ icacls $FILE /t /q /c /reset
  $ icacls $FILE /t /q /c /grant    :r Everyone:F
  $ icacls $FILE /t /q /c /setowner Administrators  
  # ====

  cmd> script.sh
    OK .. invokes bash