สิทธิ์การเข้าถึงใดที่ผู้ใช้ระดับสูงไม่สามารถละเมิดได้

23

Fr. br จอร์จบอกในหนึ่งในการบรรยายของเขา (เป็นภาษารัสเซีย) ว่ามีสิทธิ์การเข้าถึงบางส่วนที่ superuser ไม่สามารถละเมิด นั่นคือมีสิทธิ์การเข้าถึงบางอย่างที่สามารถห้ามผู้ใช้ระดับสูงทำบางสิ่งได้

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

คำถามนี้ไม่เกี่ยวข้องกับ SELinux (จอร์จพูดถึงเรื่องนี้ก่อนคำถาม)

root privileges access-control

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

2

"สิทธิ์" หรือ "สิทธิ์" เป็นสิทธิ์ในการทำบางสิ่งสิทธิที่สามารถมอบให้กับบัญชีผู้ใช้เฉพาะ ใน UNIX และ Linux (ยกเว้นรุ่นที่แข็งขึ้นเช่น SELinux) รูทมีสิทธิ์ทั้งหมด ไม่มีสิทธิที่จะได้รับที่จะเป็นและดังนั้นจึงไม่มีสิทธิที่สามารถนำออกไปจากroot root

— MSalters

1

@MSalters ให้อภัย? หนึ่งสามารถเก็บ UID 0 ในขณะที่ยังคงเพิกถอนความสามารถของกระบวนการ

— Charles Duffy

... ตั้งค่าSECBIT_NOROOTและเป็น uid 0 จะไม่มอบความสามารถหนึ่งอย่างอัตโนมัติอีกต่อไป

— Charles Duffy

คำตอบมากมาย - จะทำให้กลายเป็น wiki ชุมชนหรือควรมีคนเขียนคำตอบสรุปหรือไม่

— Simon Richter

1

@SimonRichter ฉันจะไปเป็น George เพื่อบอกเราว่าเขาหมายถึงอะไรในการบรรยายของเขา

— Kolyunya

24

acess ปฏิเสธที่จะรูท :

rootสามารถปฏิเสธการเข้าถึงเครือข่ายโดยตรง นี้จะเป็นประโยชน์ในครอบครัวที่เชื่อมต่ออินเทอร์เน็ตตามที่มันต้องการให้คุณเข้าสู่ระบบเป็นแล้วsmithsudo

บางสิ่งที่รูทไม่สามารถทำได้ :

นี่ไม่ใช่สำหรับการไม่มีสิทธิ์พิเศษ ฉันไม่เห็นสิ่งที่รูททำไม่ได้อย่างไรก็ตามปัญหาทางเทคนิคบางอย่างอาจพบว่า "ต้องห้าม"

ฉันรูททำไมฉันไม่สามารถสร้าง / ลบไฟล์นี้ในขณะที่ผู้ใช้ธรรมดาสามารถทำได้?

คุณอยู่ใน NFS / samba ที่ใช้ร่วมกันและคุณไม่ได้ให้สิทธิ์ที่เฉพาะเจาะจง ( access=) ผู้ใช้ทั่วไปไม่สามารถทำตามกฎหมายได้ (ดู local vs remote root ด้านล่าง)

ฉันหยั่งรากแล้วทำไมฉันไม่สามารถฆ่ากระบวนการนี้ได้?

มี I / O ที่รอดำเนินการและฟิสิคัลไดรฟ์ / LUN ระยะไกลถูกยกเลิกการเชื่อมต่อกระบวนการสามารถถูกฆ่าได้โดยการรีบูตเท่านั้น

ฉันหยั่งรากฉันจะรับรหัสผ่านของ archemar ได้อย่างไร

คุณสามารถsu - archemarเปลี่ยนรหัสผ่านของ archemar ได้โดยไม่ต้องรู้รหัสผ่านก่อนหน้า แต่คุณไม่สามารถอ่านได้ (ย่อมาจาก key logger) เนื่องจากรหัสผ่านจะถูกเก็บไว้โดยใช้แฮชแบบทางเดียว

โลคัล vs รีโมต root

คุณสามารถรูทบนสถานี / พีซีของคุณและใช้ บริษัท / วิทยาลัย / มหาวิทยาลัย / ผู้ให้บริการ NFS ได้
ถัดไปคุณสามารถมีล็อกอินที่ไม่ใช่รูทบนคอมพิวเตอร์ที่ส่งออก NFS

ตอนนี้

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

เพียงเข้าสู่ระบบเซิร์ฟเวอร์ NFS เรียกใช้./bashและคุณเป็น root ใน บริษัท / เซิร์ฟเวอร์มหาวิทยาลัย

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

กรณีที่ 1 นั้นเป็นข้อผิดพลาดเนื่องจากคุณอยู่rootในพื้นที่เท่านั้นไม่จำเป็นต้องอยู่ในระบบอื่น กรณีที่ 2 และ 3 ไม่ใช่สิทธิ์พิเศษ (ไม่สามารถมอบให้ใคร) ดังนั้น +1 ประโยคแรกของคุณดูเหมือนจะถูกต้อง

— MSalters

ในทางเทคนิคrootบนเครื่องท้องถิ่นสามารถทำอะไรก็ได้ที่มันชอบด้วยสิทธิพิเศษเช่นเดียวกับผู้ใช้ในท้องถิ่นโดยsu - usernameถ้าไม่มีอะไรอื่น ฉันไม่แน่ใจว่าทำไมพวกเขาถึงทำให้rootไม่สามารถเขียนแชร์เครือข่ายแบบนั้นได้ ดูเหมือนไม่มีจุดหมายเลย

— Tom Hunt

4

เป็นคำถามเก่าที่ว่า "สามารถrootสร้างรหัสผ่านได้แม้ว่าเขาจะไม่สามารถเข้าถึงได้"

— corsiKa

5

@TomHunt หนึ่งในเหตุผลที่จะไม่อนุญาตให้rootเข้าถึงการแชร์ NFS คือการป้องกันการสร้างไบนารี "suid root" บนเซิร์ฟเวอร์ระยะไกลสิ่งที่สามารถยกระดับการเข้าถึงระยะไกลไปยังเซิร์ฟเวอร์ที่สมบูรณ์

— ทำเครื่องหมาย

1

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

— แบล็กไลท์ส่องแสง

11

ในกรณีปกตินี้ไม่ถูกต้อง - superuser มีสิทธิ์ / สิทธิ์การใช้งานใด ๆ ที่ระบบให้ (1) ที่กฎนี้พังลงคือเมื่อคุณโยน SELinux ลงในส่วนผสม ด้วย SELinux มันเป็นไปได้ที่จะ จำกัด สิทธิ์ของรูทแม้จะไม่อนุญาตการกระทำบางอย่าง อย่างไรก็ตามการกระทำที่ไม่อนุญาตนั้นขึ้นอยู่กับการกำหนดค่า SELinux ของเครื่องโลคัลอย่างมากดังนั้นถึงแม้จะมี SELinux แล้วก็ตามคำถามนี้ไม่สามารถตอบได้ในแง่ทั่วไป

(1) - หากระบบไม่มีคุณสมบัติที่กำหนดเช่นไม่มีฟังก์ชันเคอร์เนลตามเวลาจริงฉันกำลังพิจารณาคำสั่ง "root ไม่สามารถเข้าถึงฟังก์ชันนี้" เป็นเท็จเนื่องจากคำสั่งนั้นอาศัย สมมติฐานที่ผิดพลาด (คือคุณสมบัติที่กำหนดให้ทุกคนในระบบนั้นสามารถใช้ได้)

— จอห์น
แหล่งที่มา

1

ขอบคุณสำหรับคำตอบของคุณจอห์น! แต่เขาระบุไว้อย่างชัดเจนว่าคำถามนี้ไม่ได้เกี่ยวข้องกับ SELinux ...

— Kolyunya

จากนั้นยกเว้นรายละเอียดเพิ่มเติมฉันจะต้องพิจารณาคำสั่งว่ารูทไม่สามารถเข้าถึงการทำงานบางอย่างเพื่อให้เป็นเท็จ (ฉันไม่ได้พิจารณากรณีของระบบปฏิบัติการที่ถูกล็อคออกจาก BIOS หรือคล้ายกันโดยการรักษาความปลอดภัย BIOS)

— จอห์น

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

— เสร็จสิ้น

2

ไม่จำเป็นต้องเป็นเรื่องจริง ถอด CAP_NET_ADMIN ออกและยังเป็น uid 0 ยังไม่ยอมให้กระบวนการเปลี่ยนการกำหนดค่าเครือข่าย (เช่นเดียวกันสำหรับ CAP_SYS_ADMIN และความสามารถที่ควบคุมเป็นต้น)

— Charles Duffy

5

ในอีกด้านหนึ่งมีสิ่งที่ผู้ใช้ไม่สามารถทำได้เช่น

ไดเรกทอรีฮาร์ดลิงก์ (เนื่องจากข้อ จำกัด ของระบบไฟล์)
เขียนไปยังซีดีรอมที่เขียนแล้ว (เพราะฟิสิกส์)

แต่นั่นไม่ใช่สิทธิพิเศษเพราะพวกเขาไม่สามารถได้รับอนุญาตพวกเขาจึงเป็นไปไม่ได้สำหรับทุกคน

จากนั้นมีข้อ จำกัด สำหรับระบบทั้งหมดหรือบางส่วนของมันที่สามารถเปิดหรือปิดได้
ตัวอย่างเช่นใน OS X มีตัวเลือกให้อนุญาตให้เรียกใช้โค้ดหากได้ลงนามโดย Apple เท่านั้น

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

แก้ไข:
ความคิดของคุณเกี่ยวกับไฟล์ที่ไม่มีบิตที่ใช้งานได้จะอยู่ในหมวดหมู่นี้เนื่องจากไม่มีใครสามารถทำเช่นนั้นได้และไม่มีใครได้รับสิทธิ์นั้น
และแม้กระทั่งเมื่อให้สิทธิ์ผู้ใช้หรือกลุ่มอื่นในการเรียกใช้ไฟล์นั้น แต่ไม่ได้รูทหรือกลุ่มผู้ใช้อยู่รูทจะยังสามารถเรียกใช้ไฟล์นั้นได้ (ทดสอบบนเซิร์ฟเวอร์ OS X 10.10, 10.11, 10.11 และ Ubuntu 15.04 เซิร์ฟเวอร์)

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

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

อย่างไรก็ตามมีระบบ (เช่น iOS) ซึ่งเป็นไปไม่ได้ (โดยพลการ) เป็นไปได้อย่างน้อยที่สุดก็ไม่ได้หากไม่มีการใช้ประโยชน์จากความปลอดภัย wholes นี่คือสาเหตุส่วนใหญ่เนื่องจากความปลอดภัยที่เพิ่มขึ้นเช่นการบังคับใช้การเซ็นชื่อรหัส
ตัวอย่างเช่นมีคีย์การเข้ารหัส AES ที่สร้างไว้ในโปรเซสเซอร์ของ iDevices ซึ่งสามารถเข้าถึงได้จากโหมดเคอร์เนลเท่านั้น โมดูลเคอร์เนลสามารถเข้าถึงสิ่งเหล่านั้นได้ แต่โค้ดในโมดูลเคอร์เนลเหล่านั้นจะต้องมีการลงชื่อโดย Apple เพื่อให้เคอร์เนลยอมรับพวกเขา

บน OS X ตั้งแต่เวอร์ชัน 10.11 (El Capitan) นอกจากนี้ยังมีสิ่งที่เรียกว่า "โหมดรูท" (แม้ว่าชื่อจะทำให้เข้าใจผิดเพราะรูทยังคงอยู่) ซึ่งจะห้ามการรูทบางอย่างที่ผู้ติดตั้งสามารถทำได้อย่างมีประสิทธิภาพ
การอ้างอิงจากคำตอบที่ยอดเยี่ยมนี้ใน AskDifferent :

นี่คือสิ่งที่ จำกัด แม้จะมาจากรูท:

คุณไม่สามารถแก้ไขอะไรใน / System, / bin, / sbin หรือ / usr (ยกเว้น / usr / local); หรือแอพและยูทิลิตี้ในตัวใด ๆ เฉพาะตัวติดตั้งและการอัปเดตซอฟต์แวร์เท่านั้นที่สามารถแก้ไขพื้นที่เหล่านี้และแม้พวกเขาจะทำเมื่อติดตั้งแพ็คเกจที่ลงนามโดย Apple เท่านั้น

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

1

ที่จริงแล้วคุณสามารถเรียกใช้ไฟล์ปฏิบัติการได้โดยไม่ต้องใช้ชุดบิตเรียกใช้งาน: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./helloให้Hello, World!ผลลัพธ์ที่คาดหวัง

— doneal24

@ DougO'Neal แต่ไม่ใช่/lib64/ld-linux-x86-64.so.2ปฏิบัติการจริงในตอนนั้นและ./helloเป็นเพียงข้อโต้แย้ง เพราะที่ผ่านเช่นแฟ้มข้อความที่มีรหัส PHP เพื่อล่าม PHP ... หรือชอบใช้สคริปต์ทุบตีใช้bash ./my_script...

— Siguza

1

@ DougO'Neal ที่ใช้ในการทำงาน แต่ถูกปิดใช้งานใน glibc รุ่นล่าสุด

— duskwuff

@duskwuff glibc รุ่นล่าสุดเป็นอย่างไร? ยังคงทำงานภายใต้ Ubuntu 14.04

— doneal24

1

Apple ไม่ได้เพิ่มลงใน ln แต่คลาสระบบที่ ln ใช้เช่นลิงก์อนุญาตให้ดูstackoverflow.com/a/4707231/151019นี่คือวิธีที่ Time Machine ทำงาน

— user151019

4

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

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

สุดท้ายโหมดจริง: rootลินุกซ์เคอร์เนลมีการสนับสนุนให้มันไม่ดังนั้นอีกครั้งไม่มีใครสามารถทำไปไม่ได้ไม่ได้

@Siguza พูดถึงการดำเนินการของไฟล์โดยไม่xได้รับอนุญาตซึ่งค่อนข้างเป็นไปได้สำหรับrootผู้ใช้:

/lib/ld-linux.so.2 /path/to/executable

— Dmitry Grigoryev
แหล่งที่มา

... แต่กระบวนการ uid-0 สามารถสูญเสียความสามารถในการโหลดโมดูลเคอร์เนลใหม่ (หรือฮอตแพชพวกเขาผ่าน/proc/kmem) ผ่านการเพิกถอนความสามารถ

— Charles Duffy

4

ตัวอย่างหนึ่งอาจแก้ไขไฟล์ที่ไม่เปลี่ยนรูปได้: คุณสามารถตั้งค่าคุณสมบัติไฟล์iด้วยchattrซึ่งทำให้ไฟล์ไม่เปลี่ยนรูปแม้สำหรับรูท ตัวอย่างเช่น:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

โปรดทราบว่าไฟล์จะปรากฏเป็นไฟล์ที่เขียนได้ปกติในls -lเอาท์พุท:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

เพื่อดูiคุณสมบัติคุณต้องใช้lsattr:

# lsattr god
----i----------- god

หน้าคู่มือของ chattrรัฐต่อไปเกี่ยวกับiแอตทริบิวต์:

ไฟล์ที่มีแอตทริบิวต์ `i 'ไม่สามารถแก้ไขได้: ไม่สามารถลบหรือเปลี่ยนชื่อได้ไม่มีการสร้างลิงก์ในไฟล์นี้และไม่สามารถเขียนข้อมูลลงในไฟล์ได้ เฉพาะ superuser หรือกระบวนการที่มีความสามารถ CAP_LINUX_IMMUTABLE เท่านั้นที่สามารถตั้งค่าหรือล้างแอตทริบิวต์นี้

แม้ว่ารูตสามารถยกเลิกการเปลี่ยนไม่ได้อย่างง่ายดาย:

# chattr -i god
# rm -v god
removed ‘god’

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

เคอร์เนลลินุกซ์ไม่ได้ใช้ระบบรักษาความปลอดภัยอย่างปลอดภัยของ BSD (อีกต่อไป) อย่างถูกต้องทำให้คุณลดผลตอบแทนจากการไม่เปลี่ยนรูปและผนวกคุณสมบัติเท่านั้น ด้วยsecurelevelบิตเหล่านี้ไม่สามารถรีเซ็ตได้เมื่อระบบอยู่ในระดับผู้ใช้หลายคนดังนั้นผู้ดูแลระบบจะต้องปิดและใช้คอนโซลภายในซึ่งจะหยุดการโจมตีเครือข่าย

— Simon Richter

2

บน FreeBSD คุณไม่สามารถใช้งานgmirrorบนพาร์ติชั่นที่เมาท์แล้วได้แม้ว่าจะเป็นรูท:

ป้ายกำกับ gmirror -v -b ต้องการ gm0s1 ad4s1
gmirror: ไม่สามารถจัดเก็บข้อมูลเมตาบน ad4s1: ไม่อนุญาตให้ใช้งาน

คุณต้องตั้งค่าsysctl(kern.geom.debugflags=16 ) เพื่อให้สามารถทำมันได้

rootเป็นผู้ใช้ที่ได้รับสิทธิพิเศษ แต่สิทธิเหล่านี้มอบให้โดยเคอร์เนล rootดังนั้นเคอร์เนลได้มีสิทธิพิเศษมากกว่า

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

1

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

สิ่งนี้ไม่ได้ป้องกันผู้ใช้รูทจากการปิดการใช้งานตัวเลือกหรือเปลี่ยนโมดูล FUSE ด้วยอันที่ทิ้งตัวเลือกอย่างเงียบ ๆ เว้นแต่คุณจะทำให้ระบบไฟล์เป็นแบบอ่านอย่างเดียว อย่างไรก็ตามสิ่งนี้นำไปสู่สถานการณ์ "ผู้เฝ้าดูยาม" เท่านั้น: คุณจะตรวจสอบได้อย่างไรว่าระบบไม่ได้โกหก? เปลือกของคุณอาจนั่งอยู่ใน chroot ที่แสดงโมดูล FUSE ที่ถูกต้องตามกฎหมายในขณะที่เคอร์เนลกำลังเรียกใช้เวอร์ชันที่เป็นอันตราย

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

0

ฉันจะบอกว่าการไม่สามารถเรียกใช้ไฟล์ที่ไม่สามารถเรียกใช้งานได้นั้นเป็นข้อ จำกัด เล็กน้อยเนื่องจากขึ้นอยู่กับการอนุญาตของไฟล์ (เป็นไปได้ที่จะหลีกเลี่ยงปัญหานี้โดยใช้ /lib64/ld-linux-x86-64.so.2 สำหรับไฟล์ nonexecutable แต่ไม่ใช่ไฟล์บนเมาท์ no-exec)

นอกจากนี้ยังมีปัญหาเรื่องการล็อกไฟล์บังคับซึ่งป้องกันการแก้ไขไฟล์หากกระบวนการกำลังถูกใช้โดยกระบวนการแม้ว่าผู้ใช้ขั้นสูงสามารถฆ่ากระบวนการได้

ณ จุดหนึ่งผู้ใช้ขั้นสูงไม่สามารถยกเลิกการต่อเชื่อมอุปกรณ์ในขณะที่อุปกรณ์ไม่ว่าง แต่ตอนนี้สามารถทำได้โดยใช้ umount ขี้เกียจ

ข้อ จำกัด อื่น ๆ :

ไม่สามารถแก้ไขไฟล์ที่ไม่เปลี่ยนรูปแบบและสามารถต่อท้ายไฟล์แบบผนวกเท่านั้น (linux ช่วยให้ผู้ใช้ขั้นสูงสามารถลบค่าสถานะที่ไม่เปลี่ยนรูปแบบและต่อท้ายเฉพาะที่ระดับการรันใด ๆ

ไม่สามารถเขียนไปที่เมาต์แบบอ่านอย่างเดียวหรือเรียกใช้สิ่งใด ๆ บนเมานต์แบบไม่เรียกใช้งาน

ไม่สามารถผูกเมานท์ที่ผูกไม่ได้

ไม่สามารถเมานต์ระบบไฟล์ใหม่เป็นอ่าน - เขียนหากอุปกรณ์บล็อกเป็นแบบอ่านอย่างเดียว

ไม่สามารถสถิติสิ่งใด ๆ บนตัวยึดฟิวส์ที่เป็นของผู้ใช้รายอื่นเว้นแต่ว่าจะมีการติดตั้ง allow-other หรือ allow-root

ไม่สามารถละเมิดการตั้งค่า SELinux

ข้อ จำกัด โดยเจตนาที่มีอยู่ในระบบซึ่งมีผลกับรูท:

ไม่สามารถตั้งค่า c-time ของไฟล์ได้โดยตรง (หรือเวลาเกิดหากมีการนำไปใช้)

ไม่สามารถดูรหัสผ่านเป็นข้อความธรรมดาได้

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