1. Implementing ACLs in Linux Jesse Dyer, Dennis Lu, and Erik Welsh Comp 527 – Fall 2001

2. Overview  Why ACLs?  Solaris ACLs  NT ACLs  Our ACLs  VFS  Our Implementation  Some Examples  Problems and Future Work

3. In case you were sleeping…  What is an ACL? Access Control List: collection of Access Control Entries (ACEs) associated with a file.  What is an ACE? A structure specifying permission for a user, group, or other entity.  What is an inode? A structure containing metadata about files and directories.

4. Why ACLs?  Traditional rwx for ugo not fine grained enough  File owner controls all permissions  Can allow group, but admin controls groups, creates administrative headache  Want to give specific user or group ability to access to files and directories

5. For Example – CVS on owlnet  Must give world rwx permissions!  Allows ANY malicious user or accident to mess up your project files  Preferably give access to certain directories to certain people

6. Solaris ACLs  Standard ACL implementation  Can give specific and multiple users and groups rwx permission on a file  Has mask entry  Almost POSIX compliant

7. NT ACLs  Even more fine grained than Solaris  Adds ability to let someone delete, modify the permissions of, or take ownership of a file  Has ability to inherit permissions  Adds ability to deny access to a file  Order to apply rules  Has “Everyone” user

8. Our ACLs  Combination of Solaris and NT ACLs  Have traditional rwx for multiple users and groups  Added p (permission)  Added inheritance  Added ability to deny  Rules applies in order

9. VFS  Acts as layer of abstraction between different filesystems and file access programs  All fs calls go through VFS at some point  Provides common interface for several fs  Different fs must register with the VFS  Different fs operations called by using function pointers

10. ext2  Default Linux file system  Allows for variable size blocks to minimize fragmentation  Variable number of inodes to maximize usable space  Block preallocation for files to reduce fragmentation  Disk blocks partitioned into groups  Robust crash recovery  Designed to be extensible (ACLs, encryption, etc…)

11. Our Implementation  Modified version of ext2 on Mandrake  Kept ACL information in the inode, not in blocks  Max users = 32  Compiled as kernel module  Modified mke2fs to setup our fs and ext2fsck to not demolish our ACLs

12. Permission Checking  If no ACL present, reverts to traditional file permissions  Search for any deny, then allow  Support for new modify permission functionality

13. setfacl  User command utility to set, modify, or delete ACLs on a file  Can be ran by file owner or anyone given permission to modify permissions  Sample commands: setfacl –s u:alice:+rx:i myFile setfacl –m o::drwx myFile setfacl –u myFile setfacl –d u:alice myFile

14. getfacl  User utility to examine the ACL on a particular file  Examines a file’s inode to detemine what permissions are set  Sample: getfacl myFile

15. Example $touch samplefile $getfacl samplefile #no ACL set $ setfacl –s u:welsh:+rw samplefile $ getfacl samplefile # file: samplefile # owner: dlu # group: brown # Inherits from parent user::rw-p:i user:welsh:rw--:i group::r---:i other:r---:i

16. Example $ setfacl –m u:welsh:dxp samplefile $ getacl samplefile # file: samplefile # owner: dlu # group: brown user::rw-p:i user:welsh:rw :i group::r---:i other:r---:i

17. Example – permission partitions DevelopmentMarketingQA

18. Problems  Open Source code is inconsistently documented  Communication between kernel and user programs is confusing  Testing is a pain

19. Future Work  Make it as a patch to the current linux distribution  Determine the optimum number of ACLs to be kept  Caching effective ACLs minimizes performance hit from inheritance  Graphical User Interface

20. The Ideal ACL  Deny and allow have equal importance, based on their location in the ACL. I.e. Order matters.  Example User Chuck member of: everyone, losers. ACL: allow Chuck; deny losers; allow everyone  Chuck is given access. Existing implementation  Chuck is denied access

21. References   Bovet and Cesati, Understanding the Linux Kernel, O’Reilly, 2001  Anderson, Security Engineering, Wiley, 2001  Linux Documentation Project  Algis  Dan