คำอธิบายเกี่ยวกับ chown (1) ข้อมูลจำเพาะ POSIX

ข้อมูลจำเพาะ POSIX สำหรับchownยูทิลิตี้กล่าวถึงในส่วนของเหตุผลเกี่ยวกับchown user:groupไวยากรณ์ (เดิมchown user.group) (เน้นเหมือง):

วิธี 4.3 BSD ในการระบุเจ้าของและกลุ่มถูกรวมไว้ในเล่มนี้ของ POSIX.1-2008 เพราะ:

• มีหลายกรณีที่ไม่สามารถบรรลุเงื่อนไขสิ้นสุดที่ต้องการได้โดยใช้ยูทิลิตี chgrp และ chown (ที่เปลี่ยนเฉพาะยูสเซอร์ ID) (หากเจ้าของปัจจุบันไม่ได้เป็นสมาชิกของกลุ่มที่ต้องการและเจ้าของที่ต้องการไม่ใช่สมาชิกของกลุ่มปัจจุบันฟังก์ชัน chown () อาจล้มเหลวเว้นแต่เจ้าของและกลุ่มจะเปลี่ยนไปในเวลาเดียวกัน)

ฉันคิดว่าuser:groupไวยากรณ์เป็นสิ่งอำนวยความสะดวก ตอนนี้หมายถึงมีสิ่งที่คุณสามารถทำได้ด้วยchown user:groupสิ่งที่คุณไม่สามารถทำได้chgrp group; chown user

ตอนนี้ข้อความนั้นไม่สมเหตุสมผลสำหรับฉัน ใน 4.3BSD เฉพาะ root เท่านั้นที่สามารถเปลี่ยนเจ้าของไฟล์ได้ไม่ว่าในกรณีใด ๆ ก็ไม่มีข้อ จำกัด ในสิ่งที่เขาสามารถทำได้

SysV และระบบอื่น ๆ ไม่กี่อนุญาตให้ (หรือใช้เพื่ออนุญาต) เจ้าของไฟล์ที่จะเปลี่ยนผู้ใช้และกลุ่มของไฟล์เป็นอะไร แต่แม้ในระบบเหล่านั้นข้อความข้างต้นไม่สมเหตุสมผลกับฉัน ตกลงถ้ามีคนทำchown someone-else the-fileไม่สามารถทำได้chgrp something-else the-fileหลังจากนั้นเพราะไม่มีเจ้าของไฟล์อีกต่อไป แต่ไม่มีอะไรขัดขวางเขา / เธอจากการทำchgrpครั้งแรก (อยู่ที่เจ้าของไฟล์) และchownหลังจากนั้นและนั่นไม่ใช่สิ่งที่ ข้อความด้านบนพูดอย่างแน่นอน

ฉันไม่เข้าใจว่าเจ้าของที่ต้องการไม่ใช่สมาชิกของกลุ่มปัจจุบันเกี่ยวข้องกับปัญหาอย่างไร

ดังนั้นเงื่อนไขใดที่ฟังก์ชัน chown () อาจล้มเหลวเว้นแต่เจ้าของและกลุ่มจะเปลี่ยนไปในเวลาเดียวกันและในระบบใด

Microsoft Interix Unix ระบบย่อย (ตอนนี้เกษียณ)สำหรับเคอร์เนลของ NT กระทำเล็ก ๆ น้อย ๆ ที่แตกต่างกันด้วยสิทธิ์ผู้ใช้และกลุ่มกว่าคนอื่น ๆ บางคนทำ:

ข้อมูลผู้ใช้และกลุ่มถูกเก็บไว้ในฐานข้อมูลการเข้าถึงความปลอดภัย ทั้งผู้ใช้และกลุ่มจะถูกเก็บไว้ในฐานข้อมูลเดียวกัน แต่ชื่อกลุ่มและผู้ใช้จะต้องไม่ซ้ำกัน ไม่มีกลุ่มใดสามารถมีชื่อผู้ใช้และในทางกลับกัน (ฐานข้อมูลนี้แทนที่/etc/passwdและ/etc/groupsไฟล์ใน UNIX)ผู้ใช้และกลุ่มถูกสร้างขึ้นโดยใช้วิธีการ Windows ที่เหมาะสม(ตัวจัดการผู้ใช้ผู้ใช้ของไดเรกทอรีที่ใช้งานอยู่และคอมพิวเตอร์หรือผู้ใช้และกลุ่มภายใน)หรือด้วยnet userคำสั่งWin32 (ตัวอย่างเชลล์สคริปต์เพื่อสร้างและลบผู้ใช้ถูกรวมอยู่ในไดเรกทอรี/usr/examples/admin)ผู้ใช้สามารถอยู่ในกลุ่มได้หลายกลุ่ม

นี่คือบางส่วนตัดตอนคู่มือเฉพาะเจาะจงมากขึ้น:

ใน Windows ผู้ใช้หรือกลุ่มสามารถเป็นเจ้าของวัตถุได้ สิ่งนี้แตกต่างจาก UNIX ซึ่งมีเพียงผู้ใช้ที่เป็นเจ้าของวัตถุ

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

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

chgrp

... เปลี่ยน ID กลุ่มสำหรับไฟล์ ... ผู้ใช้ที่เรียกใช้ chgrp (1) จะต้องเป็นสมาชิกของกลุ่มที่ระบุและเป็นเจ้าของไฟล์หรือมีสิทธิ์ที่เหมาะสม

chown

... ตัวถูกดำเนินการทั้งเจ้าของและกลุ่มนั้นเป็นทางเลือก อย่างไรก็ตามต้องระบุหนึ่งรายการ หากระบุตัวถูกดำเนินการกลุ่มจะต้องนำหน้าด้วยโคลอน (:)

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

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

ดังที่ฉันได้อ่านนั่นหมายความว่าหากบัญชีผู้ใช้ของคุณเป็นของกลุ่ม Windows ที่มีสิทธิ์เพียงพอที่จะแก้ไขสิทธิ์ของไฟล์ที่กลุ่มนั้นเป็นเจ้าของก็เป็นไปได้chgrpที่ไฟล์ดังกล่าวจะอยู่นอกการควบคุมบัญชีผู้ใช้ของคุณ จำนวนนี้เป็นการควบคุมที่น้อยกว่าที่คุณอาจมีchownและuser:groupพารามิเตอร์ที่ชัดเจน ในบริบทนั้นโดยไม่มีความเป็นไปได้ที่จะประกาศuser: และ :groupคุณจะไม่สามารถบรรลุผลลัพธ์เดียวกันได้

นี่คือลิงค์ไปยังรายละเอียดเกี่ยวกับวิธีที่ Interix โต้ตอบกับ Windows ACLs โดยมุ่งเน้นที่ความรู้ดังกล่าวอาจนำไปใช้กับระบบไฟล์ Samba ใน Unix รุ่นอื่น ๆ

นี่คือลิงค์ไปยังเอกสาร Solaris ที่ล้าสมัยในขณะนี้ซึ่งอธิบายถึง tunable rstchownที่ ...

ระบุว่าซีแมนทิกส์ POSIX สำหรับการchown(2)เรียกระบบมีผล ...

เห็นได้ชัดว่าหากพารามิเตอร์ถูกตั้งค่าเป็น0...

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

ตัวเลือกดังกล่าวไม่ได้ทำให้POSIXของ Solaris ไม่สอดคล้องกัน เพียงแค่ว่ามันเป็นตัวเลือกที่ทุกคนมีคุณสมบัติมันตามมาตรฐาน :

แม้ว่าการใช้งานทั้งหมดที่สอดคล้องกับ POSIX.1-2008 สนับสนุนคุณสมบัติทั้งหมดที่อธิบายไว้ด้านล่างอาจมีขั้นตอนการกำหนดค่าที่ขึ้นอยู่กับระบบหรือระบบไฟล์ที่สามารถลบหรือแก้ไข คุณสมบัติเหล่านี้ใด ๆ หรือทั้งหมด ไม่ควรทำการกำหนดค่าดังกล่าวหากจำเป็นต้องปฏิบัติตามอย่างเคร่งครัด

ค่าคงที่เชิงสัญลักษณ์ต่อไปนี้จะถูกกำหนดด้วยค่าอื่นที่ไม่ใช่ -1 หากคงถูกกำหนดให้กับศูนย์ค่าการใช้งานควรใช้sysconf(), pathconf()หรือfpathconf()ฟังก์ชั่นหรือ getconfยูทิลิตี้เพื่อตรวจสอบคุณสมบัติที่มีอยู่ในระบบในเวลานั้นหรือชื่อพา ธ โดยเฉพาะอย่างยิ่งในคำถาม

_POSIX_CHOWN_RESTRICTED

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

chown()การทำงานของระบบ - ซึ่งเป็นสายระบบเอกสารที่ทำโดยทั้งสองchownและchgrpสาธารณูปโภคเชลล์ - มีการระบุที่จะล้มเหลวด้วยเหตุผลต่าง ๆ นานา ในหมู่พวกเขา:

EACCES สิทธิ์การค้นหาถูกปฏิเสธในส่วนประกอบของคำนำหน้าเส้นทาง

ELOOP การวนซ้ำมีอยู่ในลิงก์สัญลักษณ์ที่พบระหว่างการแก้ไขอาร์กิวเมนต์พา ธ

EPERM ID ผู้ใช้ที่มีประสิทธิภาพไม่ตรงกับเจ้าของไฟล์หรือกระบวนการเรียกไม่มีสิทธิ์ที่เหมาะสมและ_POSIX_CHOWN_RESTRICTEDระบุว่าต้องการสิทธิ์ดังกล่าว

อย่างไรก็ตามพฤติกรรมของการให้สิทธิ์การปรับเปลี่ยนสิทธิ์ให้กับผู้ใช้ที่ไม่ใช่รูทนั้นไม่เคยมีลักษณะเฉพาะกับ Solaris มีดีมาก - ถ้าค่อนข้างเก่า - ครอบคลุมสิทธิ์ของไฟล์ Unix ในโพสต์ฟอรั่มนี้ที่ผู้เขียนระบุ:

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

วันนี้มันไม่ง่ายเลยที่จะบอกว่าไฟล์ที่ไม่ใช่รูทสามารถทำได้chownหรือไม่ ระบบปฏิบัติการยูนิกซ์หลายรุ่นอนุญาตพฤติกรรมทั้งสองอย่าง ...

ข้อดีอีกข้อหนึ่ง - และอื่น ๆ ล่าสุด - การโพสต์รายการส่งจดหมายราคานี้และดำเนินการต่อ:

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

ฉันคิดว่าย่อหน้าสุดท้ายพูดได้ดี

บทความที่ยังมีการอ้างอิงCAP_CHOWNในการควบคุมสถานที่บน Linux (ที่ควรจะส่งผลกระทบต่อPOSIX_CHOWN_RESTRICTEDพฤติกรรม) นอกจากนี้ยังมีCAP_FOWNERความสามารถที่แตกต่างกันเล็กน้อยในพฤติกรรม

และในขณะที่คุณชี้ให้เห็นในปี 2003 :

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

... ซึ่งขึ้นอยู่กับsetprivgroupพารามิเตอร์การกำหนดค่า

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

ในสถานการณ์นี้chown แล้ว chgrpจะไม่เป็นผู้ใช้จะไม่ได้รับอนุญาตให้เปลี่ยนสิทธิ์ของแฟ้มที่ขณะchown user:group- ตราบใดที่กลุ่มเป็นหนึ่งในผู้ใช้ของตัวเอง - จะประสบความสำเร็จ

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

นอกจากนี้ยังมีเอกสารครอบคลุมเกี่ยวกับผลกระทบต่าง ๆ ที่เป็นไปได้ของการอนุญาตไฟล์, ท-Rราเวิลทรีและลิงก์สัญลักษณ์ที่อาจทำให้เกิดความล้มเหลวคล้ายกันโดยคำนึงถึงchownแอปพลิเคชันเชิงนิเวศน์

จากPOSIX XRATส่วนหัวโดเมนที่สามและสี่ :

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

... มีปัญหาด้านความปลอดภัยที่ต้องเริ่มต้นด้วยการเดินแบบลอจิคัล ในอดีตchown -Rไฟล์ผู้ใช้คำสั่งมีความปลอดภัยสำหรับ superuser เนื่องจากบิตsetuidและsetgidหายไปเมื่อความเป็นเจ้าของไฟล์ถูกเปลี่ยน หากการเดินนั้นมีเหตุผลการเปลี่ยนความเป็นเจ้าของจะไม่ปลอดภัยอีกต่อไปเพราะผู้ใช้อาจแทรกลิงก์สัญลักษณ์ที่ชี้ไปยังไฟล์ใด ๆ ในทรี อีกครั้งสิ่งนี้จะทำให้การเพิ่มตัวเลือกในคำสั่งที่ทำการข้ามลำดับชั้นไม่ใช่ทางอ้อมผ่านการเชื่อมโยงสัญลักษณ์และสคริปต์ทางประวัติศาสตร์ที่ทำการเดินแบบเรียกซ้ำจะกลายเป็นปัญหาด้านความปลอดภัยทันที แม้ว่านี่จะเป็นปัญหาสำหรับผู้ดูแลระบบ แต่ส่วนใหญ่จะไม่มีค่าเริ่มต้นที่แตกต่างกันสำหรับคลาสของผู้ใช้ที่ต่างกัน

...

ใน 4.3 BSD chgrpในระหว่างการแวะผ่านต้นไม้เปลี่ยนกลุ่มของลิงก์สัญลักษณ์ไม่ใช่เป้าหมาย ลิงก์สัญลักษณ์ใน 4.4 BSD ไม่มีเจ้าของกลุ่มโหมดหรือคุณลักษณะไฟล์ระบบ UNIX มาตรฐานอื่น ๆ

และจากchgrpหน้าPOSIX ถูกต้องมีสิ่งนี้ชี้ไปที่-Rการกระทำเชิงนิเวศที่ไม่สมบูรณ์ที่เป็นไปได้หรืออย่างน้อยก็เป็นสิ่งที่เคยเป็น:

เวอร์ชัน System V และ BSD ใช้รหัสสถานะการออกที่แตกต่างกัน การใช้งานบางอย่างใช้สถานะการออกเป็นจำนวนข้อผิดพลาดที่เกิดขึ้น การปฏิบัตินี้ไม่สามารถใช้การได้เนื่องจากสามารถล้นช่วงของค่าสถานะการออกที่ถูกต้อง ผู้พัฒนามาตรฐานเลือกที่จะปกปิดสิ่งเหล่านี้โดยการระบุเพียง 0 และ> 0 เป็นค่าออก

อัสสัมชั 1: กฎระเบียบในการพิจารณาว่าประสบความสำเร็จในการตรวจสอบส่วนผู้ใช้เป้าหมายและกลุ่มที่เป็นอิสระเช่นพวกเขาจะอยู่ในรูปแบบchownuser_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters)

อัสสัมชัญ 2: chown(file, -1, -1)สำเร็จ

ข้อสันนิษฐานที่ 3: กฎสำหรับการพิจารณาว่าchownสำเร็จไม่ได้ขึ้นอยู่กับกลุ่มของไฟล์ที่อยู่ในปัจจุบัน

ผลที่ตามมา: ถ้าchown(file, uid, gid)จะประสบความสำเร็จก็จะเป็นchown(file, -1, gid) && chown(file, uid, -1)เช่นนั้น

ฉันไม่รู้ตัวแปร Unix ที่จะละเมิดสมมติฐานใด ๆ เหล่านี้พวกเขาดูเหมือนปลอดภัย

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

กรณีที่ข้อสันนิษฐานที่ 3 อาจผิดอยู่ในระบบที่กระบวนการสามารถรับความสามารถในการเปลี่ยนเจ้าของไฟล์ แต่ถ้าพวกเขามีสิทธิ์เขียนบนไฟล์ ในขณะที่ค่อนข้างเหมือนจริงฉันไม่ทราบว่าระบบใดเป็นกรณีนี้ จากนั้นchgrpไปยังกลุ่มจากกระบวนการที่ทำงานไม่เป็นรากหรือเป็นผู้ใช้ที่เป็นเจ้าของไฟล์อาจทำให้ไฟล์ปิดขีด จำกัด chownสำหรับในภายหลัง

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

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied