CS 3210 Fall 2006

1
CS 3210Fall 2006

• Access Control
• Lists (ACLs)

2
Overview

• ACLs provide fine-grain control over access
• Augment existing owner, group, other (rwx)
• Other bits setuid, setgid, sticky bit
• Based on a POSIX non-standard ?
• Available in the 2.6 kernel and most other vendor
  UNIXes but some incompatibilities
• User-level utilities getfacl, setfacl
• Implemented using Extended Attributes (EA)

3
Basic Ideas

• A per-file set (list) of ACL entries
• Each entry provides permissions for
• Named user userpwhrw-
• Named group groupfacr-x
• Traditional mode bits grouprwx, other---
• Important for ACLs to work seamlessly with
  existing permission model
• Apps that are not ACL-aware should still work
  properly

4
Minimal and Extended ACLs

• A file with no special ACLs added is said to have
  minimal ACLs
• One entry for owner, group, other
• All files always have three minimal entries
• (at least conceptually)
• Files with more than three entries is said to
  have extended ACLs
• Extended ACLs include a special mask entry
• Mask entry helps models work together properly

5
Combined Model

• The group entry in the conventional model defines
  permission for the owning group
• Recall that users may be in more than one group
  but not files (under the conventional model)
• Under the combined model all user and group
  entries are said to define the group class
  (which contains the owning group entry)

6
mask Entry

• Lets say a file is owning group readable but
  also writable by joe
• The group class permissions no longer correspond
  to the owning group permissions
• A new mask entry is added that defines the upper
  bound of group class permissions
• Things that ANY group or user can do
• The UNION

7
Effective Permissions

• chmod operates on group class (mask)
• Group class can disable (mask) other permissions
• Effective permission computed by ANDing bits
• Example
• Named user userjoer-x (101)
• mask maskrw- (110)
• Effective permission r-- (100)
• getfacl prints effective permission (comment)
• getfacl file ? userjoerw effective r-x

8
Default ACLs

• Two flavors
• Access ACLs (what we just talked about)
• Default ACLs
• Permissions associated with directories
• Directories can have both access and default
• New files inherit default ACLs of parent
  directory as their access ACLs
• Subdirectories inherit both
• Permissions further modified by creat() mode
• umask has no effect when default ACLs are present

9
Examples (1)

• getfacl dir
• file dir
• owner agruen
• group suse
• userrwx
• groupr-x
• other---
• setfacl m userjoerwx dir (modify)

10
Examples (2)

• getfacl omit-header dir
• userrwx
• userjoerwx
• groupr-x
• maskrwx
• other---
• ls l dir
• drwrwx--- agruen suse dir

11
Examples (3)

• chmod g-w dir
• ls dl dir
• drwxr-x---
• getfacl omit-header dir
• userrwx
• userjoerwx effectiver-x
• groupr-x
• maskr-x
• other---

12
Examples (4)

• chmod gw dir
• ls dl dir
• drwxrwx---
• getfacl omit-header dir
• userrwx
• userjoerwx
• groupr-x
• maskrwx
• other---

13
Default ACL Examples

• See paper

14
Access Check Algorithm

• Complex but well-detailed algorithm
• Find closest matching ACL entry
• Look in order owner, named user, group, others
• Any matching group entry (with permission) is
  fine
• A single entry needed to determine access

15
Access Check Algorithm (2)

• Step 1
• if owner, use owner entry
• else if named entry, use named entry
• else if in owning group, use owning group entry
• else if in named group with permission, use that
• else if permission denied by named group or user,
  deny
• else user other entry
• Step 2
• grant if matching entry provides access and is
• owner or other OR
• named user/group, owning group AND mask gives
  access

16
Extended Attributes (1)

• ACLs represent additional file meta-data
• Problem no space in inode!
• Instead of ad-hoc solution, Linux added a general
  mechanism for meta-data
• Extended Attributes (EA)
• man 5 attr
• arbitrary key-value pairs
• setfattr n key v value foo
• getfattr n key foo

17
Extended Attributes (2)

• EA has per-filesystem implementation
• Ext2/3 implementation
• Per-file EA block (i_facl_block field in inode)
• Fixed-size (all EAs must fit in one block)
• Complex sharing optimization (between files)
• Caching, LRU lists for efficient access
• Key/value treated as un-interpreted binary data
• Note ACLs slow access
• Disk access to get ACLs on open
• Regular permissions are stored in inode

18
ACL Implementation

• Per-filesystem implementations
• libacl, user-level utilities, kernel support
• No getfacl(), setfacl() system calls
• Uses getfattr(), setfattr() system calls instead

19
Performance

• See paper for performance studies
• Significant cost for file create, open
• Amortized over file access
• Most significant for small, short-lived files
• Which are very common, actually
• Implementations not highly optimized

20
Issues

• ACLs provide useful capabilities
• Some extra work for users, sysadmins
• Cognitive complexity to understand model
• Not implemented for all filesystems
• Subtle differences between vendors
• Applications must be ACL-aware to benefit
• No kernel file copy
• Apps open one file, create another, copy bits
• New file must preserve ACLs
• Only possible if copy application is ACL-aware