Implementing Native NFSv4 ACLs in Linux

The NFSv4 standard defines an advanced security model which provides detailed and flexible Access Control Lists. These allow system administrators very fine-grained control of user privileges over files.

Unlike the traditional POSIX access model using a 9-bit mask, NFSv4 ACLs allow privileges to be granted to more detailed sets of users than just the file's owner, the file's group, or everyone else. For example, you can express rules like "all the people in Accounts can read this file, the Auditors can read this file, Fred can write it, and nobody else can read or write it".

Unlike the draft POSIX standard ACL model, NFSv4 ACLs provide a finer grained set of privileges that can be granted, and also allow
the system administrator to deny privileges as all grant them. This makes it much easier to express some security policies. For
example, you can express rules like "all the people in Accounts can read this file, except Jane".

SE/Linux fans please note: this is Discretionary Access Control,
*not* Mandatory Access Control nor Multi Level Security.

Linux supports NFSv4 ACLs...kinda. Few filesystems support NFSv4 ACLs, so ACLs usually only come into play when files are being accessed remotely via NFS or CIFS. For example, the NFS server and Samba can use native filesystem support for POSIX ACLs to implement poor approximations of NFSv4 ACLs. There are a number of technical difficulties with this approach which make it unattractive.

On the other hand, NFSv4 ACLs are rather an attractive feature of a NAS file server, especially one where Windows clients using the CIFS protocol need to co-exist with Linux clients using NFS. The NFSv4 ACL model is quite close (but not identical) to the Windows model, so the mapping is relatively straightforward.

In 2008 SGI decided to implement end-to-end native NFSv4 ACL support as part of our NAS file server product. In collaboration with Andreas Gruenbacher of SUSE, we conducted a cross-team effort including contributions to XFS, ext3, the Linux VFS, Samba, and the NFS server and client.

In this talk I'll describe how the NFSv4 ACL model works, and contrast it to the POSIX model you're probably more familiar with. I'll cover the theoretical and practical challenges we encountered when choosing what parts of the standard to implement and how accurately to implement them. I'll talk about the organisational challenges involved, and briefly cover how the code hangs together.

People with an interest in kernel development, enterprise file serving, networking, or security will get the most out of this talk.

Transcript

1. Headline in Arial Bold 30pt Implementing Native NFSv4 ACLs in Linux Greg Banks <gnb@sgi.com> Principal Engineer Silicon Graphics, Inc.
2. 01/23/09 Slide 2 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea
3. 01/23/09 Slide 3 Who Is Greg? • Principal Engineer, Fileserving Technologies, SGI • Located in Melbourne...currently • Linux on and off since 1999 • NFS since 2002
4. 01/23/09 What are ACLs? • ACL = Access Control List • ACLs allow a sysadmin to express non­trivial rules defining access control on objects (e.g. files or directories) • e.g., “all the people in Accounts can read this file, and the Auditors can read this file, and Fred can write it, but nobody else can read or write it”
5. 01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea
6. 01/23/09 What Is An Access Model? • Subject = entity which performs actions • Object = entity on which actions are performed • Definition of format for subject credentials • Definition of format for object permissions • Set of actions a subject can perform • Algorithm – allowed = f(subject­credentials, object­permissions, action­requested)
7. 01/23/09 Access Models For Filesystems • Subject = process • Object = inode, i.e. file or directory or other object • Subject credentials = an owner, some groups • Object permissions = an owner, an owning group, a POSIX mode and/or some kind of ACL • Actions e.g. Read, Write, Execute, Delete, Change Owner • Algorithm might use the permissions of the parent directory
8. 01/23/09 Some Access Models For Filesystems • Traditional POSIX • Draft POSIX ACLs • Windows NT ACLs • NFSv4 ACLs
9. 01/23/09 Access Models...Graphically Windows ACLs Trad POSIX Draft POSIX ACLs NFSv4 ACLs
10. 01/23/09 Traditional POSIX • Original Bell Labs model from early 1970s – Has the virtue of simplicity • Owners & groups identified by UIDs, GIDs – 16b or 32b integers – locally mapped on each system (e.g. /etc/passwd, NIS, LDAP) – e.g. 16345 • 3 bit access mask – Read (r), Write (w), Execute (x) • Most actions are mapped to one of these 3 – exceptions, e.g. Delete => Write on the parent directory
11. 01/23/09 Traditional POSIX (2) • Subjects classified into one of 3 classes – Owner = the subject's owner matches the object's, or – Group = one of the subject's groups matches the object's owning group, or – Other = none of the above • 1 access mask per class = 9 bits • + setuid, setgid, sticky bits = 12 bit mode
12. 01/23/09 Traditional POSIX: Access Algorithm • Classify subject by matching UIDs and GIDs • Use class to choose one of the 3 access masks • If desired bit is set access is allowed, else denied
13. 01/23/09 Draft POSIX ACLs • Draft POSIX extensions 1003.1e and 1003.2c – never ratified – but implemented several times – simply extends POSIX to allow more entries • Users & groups UIDs/GIDs (same) • 3 bit access mask (same) • 3 special classes (same) – Owner (tag ACL_USER_OBJ), Group (ACL_GROUP_OBJ), Other (ACL_OTHER) • 1 entry per each special class
14. 01/23/09 Draft POSIX ACLs (2) • Any number of additional entries (ACEs) – General user (ACL_USER), general group (ACL_GROUP) – Total between 3 .. _POSIX_ACL_ENTRIES_MAX (>= 16) entries – Order not significant • Entries only allow access, never deny access – Access not explicitly allowed is implicitly denied
15. 01/23/09 Draft POSIX ACLs: Access Algorithm • (simplified) • If subject UID matches an ACL_USER or ACL_USER_OBJ entry, use that • Else if subject GIDs match an ACL_GROUP_OBJ or ACL_GROUP entry, use that • Else use the ACL_OTHER entry
16. 01/23/09 Windows ACLs • From Microsoft – Implemented in Windows NT – Minor changes in subsequent releases • Users & groups identified by SIDs (Security Identifiers) – Like a variable­length enormous binary UID but with global scope – e.g. S­1­5­21­1004336348­1177238915­682003330­512 • 14 access mask bits – ReadData/ListFolder, WriteData/CreateFile, AppendData/CreateFolder, ReadExtendedAttributes, WriteExtendedAttributes, Execute/TraverseFolder, DeleteChild, ReadAttributes, WriteAttributes, Delete, ReadPermissions, WritePermissions, TakeOwnership, Synchronize
17. 01/23/09 Windows ACLs (2) • Variable number of ACEs – Up to 64K size = ~1800 ACEs – Entry has a SID, a type, some flags, and an access mask – Order significant • 3 useful special classes (Well­Known SIDs) – Creator Owner, Creator Group, Everyone • Several less helpful Well­Known SIDs – Interactive, Network, Dialup, Batch, Anonymous, Authenticated, Service etc • Any number of other SIDs – general user, general group
18. 01/23/09 Windows ACLs (3) • Entry type – AccessAllowed = subject is allowed the access bits – AccessDenied = subject is denied the access bits – SystemAudit = wacky audit stuff • Entry flags – INHERITED, INHERIT_ONLY, CONTAINER_INHERIT, OBJECT_INHERIT, NO_PROPAGATE_INHERIT – supports inheritance – SUCCESSFUL_ACCESS, FAILED_ACCESS – wacky audit stuff • ACL flags – Actually in the containing Security Descriptor – AUTO_INHERITED, DEFAULTED, PROTECTED
19. 01/23/09 Windows ACLs: Access Algorithm • (simplified) • Loop through each entry – stop if entry's SID matches any of subject's SIDs • If matching entry is Allow, access allowed • If matching entry is Deny, access denied • If no matching entry, access denied • TODO:re­express this dammit – matching on access mask?
20. 01/23/09 NFSv4 ACLs • Defined in NFSv4 standards – original NFSv4 RFC3010 – clarified in RFC3530 – modified, clarified further in upcoming NFSv4.1 RFC • Tries to make the Windows access model usable over NFS – without admitting it's Windows – obviously nobody implemented it before writing the RFC – architecture very similar to Windows, differs only in details • Users & groups identified by strings – “user@domain” or “group@domain” – for transmission; systems expected to map these to some other local form like UIDs
21. 01/23/09 NFSv4 ACLs (2) • 14 access mask bits – Binary values identical to Windows – Names and semantics...similar...to Windows – NFSv4.1 adds 2 more which have no equivalent in Windows • 3 useful special classes (whos) – OWNER@, GROUP@, EVERYONE@ – Nearly identical to Windows • Several unhelpful special classes – Blindly copied from Windows – But much less helpful in an NFS context • Variable number of other entries TODO:rephrases – General user, general group
22. 01/23/09 NFSv4 ACLs (3) • Any number of entries – No defined limit • Entry type – Blindly copied from Windows – Including audit • Per­entry flags – Blindly copied from Windows – Added ACE4_IDENTIFIER_GROUP to tell apart user & group whos • Per­ACL flags – Blindly copied from Windows – Not in NFSv4, added in 4.1
23. 01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea
24. 01/23/09 Advantages of NFSv4 ACLs • Expressibility of Deny­type ACEs – e.g. “all the people in Accounts can read this file, except Tall Jan” – Real­world usefulness ??? • Theoretically, finer grain access control – Some NFSv4 access rights make little sense in POSIX – Judging by Windows programming examples, most ACLs use only “Full Control” “Read Only”. – Real­world usefulness ??? • Use the same ACLs for files on NAS filesystems used by both POSIX and Windows systems
25. 01/23/09 Disadvantages of NFSv4 ACLs • Significantly more complex than Traditional POSIX – Security through complexity? • Deny­type ACEs complicate all algorithms for handling ACLs • Inheritance...subtle and unobvious • Order of ACEs is significant – Can be confusing, subtle • EVERYONE@ who != POSIX Other class – But sufficiently similar to cause confusion – Also complicates algorithms
26. 01/23/09 Disadvantages of NFSv4 ACLs (2) • Must retain POSIX mode for compatibility – gymnastics to preserve semblance of POSIX chmod() semantics – need extra state to do this properly...state not exportable in NFSv4 • NFSv4 standard børked – vague descriptions of access rights – several corner cases poorly defined – forgot to include per­ACL flags – no implementation completely follows the standard • POSIX has no atomic create­with­xattr or create­with­ACL
27. 01/23/09 “Rich” • The NFS version 4 ACL model is quite rich – RFC 3530
28. 01/23/09 “Rich” • The NFS version 4 ACL model is quite rich – RFC 3530 • If you've dealt with Microsoft you know what this means • rich (n) overly complex, ill­defined, poorly considered, riddled with subtle bugs. • Translation into the NFS world did not improve matters
29. 01/23/09 Who implements NFSv4 ACLs? • ZFS from Sun • GPFS from IBM • Linux NFS server, client – kinda...
30. 01/23/09 Problems With Current Linux NFSv4 ACLs • Server assumes underlying filesystem does POSIX ACLs – Converts to POSIX ACL when client sets an ACL – Converts from POSIX ACL when client gets an ACL – In general this conversion is lossy – Samba is doing (hopefully) the same conversion in userspace • Client presents ACLs in an unexpected manner – Non­standard Extended Attribute, formatted as NFSv4 XDR – Need special utilities to set, print – These utilities are different to what's used on the server – Problems with cp, tar
31. 01/23/09 So Why Care? • NFSv4 ACLs are more expressive – e.g. Deny ACEs, inheritance control – you might learn to like that extra power • You have a mixed Windows/Linux environment – with global access policies – and files being shared between both clients – over both NFS and CIFS protocols
32. 01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea
33. 01/23/09 SGI's NFSv4 ACL project • Inspired by Andreas Grünbacher's talk at LCA 2007 • Goals: – develop native NFSv4 ACL support for Linux XFS, NFS server and client – ship native NFSv4 ACL support for XFS, NFS server, Samba in SGI's NAS server product • Cross­team effort – Theory, core nfs4acl utilities, ext3 patch, VFS: Andreas G – XFS: Tim Shimmin, Donald Douwsma, Barry Naujok – NFS: Greg Banks – Samba: David Disseldorp • Started just after LCA 2008
34. 01/23/09 Architecture: Local Applications
35. 01/23/09 Architecture: Using NFS
36. 01/23/09 Architecture: Using CIFS
37. 01/23/09 Project Scope • Kernel – VFS – allow a filesystem more control over access checks – New NFSv4 ACL Kernel API – infrastructure – ext3 – store and enforce NFSv4 ACLs – XFS – store and enforce NFSv4 ACLs – NFS server – support ACL get and set operations from clients – NFS client – provide interface to userspace to get and set ACLs • Userspace – New NFSv4 ACL Userspace API – infrastructure – Samba – use API to get and set ACLs – Commandline utility, test suites • Configure and package for SGI's NAS server
38. 01/23/09 VFS Changes • New inode_operations – may_delete: a filesystem can hook into permission checking for file deletion – may_create: a filesystem can hook into file and directory creation • New superblock flag – MS_WITHAPPEND: a filesystem can tell the VFS to pass down the MAY_APPEND flag to inode_operations­>permission • Surprisingly, that was all
39. 01/23/09 New NFSv4 ACL Kernel API • New generic filesystem code – fs/nfs4acl_{base,compat,xattr}.c – include/linux/nfs4acl{,_xattr}.h – CONFIG_FS_NFS4ACL=y • Provides infrastructure for all filesystems to share • Hides most of the details of NFSv4 ACLs • Replaces existing NFS4 ACL code – which lives in fs/nfsd/ so XFS cannot use it – was mostly concerned with mapping to POSIX ACLs & back – did not do access checks etc
40. 01/23/09 New NFSv4 ACL Kernel API: Features • Data structures – struct nfs4acl, struct nfs4ace • Iterate entries – #define nfs4acl_for_each_entry • Memory management – struct nfs4acl *nfs4acl_alloc(int count) – struct nfs4acl *nfs4acl_clone(const struct nfs4acl *acl) – struct nfs4acl *nfs4acl_get(struct nfs4acl *acl) – void nfs4acl_put(struct nfs4acl *acl) • Logic – int nfs4ace_is_everyone(const struct nfs4ace *ace)
41. 01/23/09 New NFSv4 ACL Kernel API: Features (2) • Access check algorithm – int nfs4acl_permission(struct inode *, const struct nfs4acl *, unsigned int) • Maintaining POSIX inode mode – void nfs4acl_compute_max_masks(struct nfs4acl *) – int nfs4acl_masks_to_mode(const struct nfs4acl *) – struct nfs4acl *nfs4acl_chmod(struct nfs4acl *, mode_t) • Inheritance – struct nfs4acl *nfs4acl_inherit(const struct nfs4acl *, mode_t) • Binary Encoding for xattrs – struct nfs4acl *nfs4acl_from_xattr(const void *, size_t) – void nfs4acl_to_xattr(const struct nfs4acl *, void *)
42. 01/23/09 ext3 Changes • CONFIG_EXT3_FS_NFS4ACL=y • “acl” mount option can now take a value: acl=nfs4 • New xattr “system.nfs4acl” – Name & format defined by NFS4 ACL API • In­core ACL cached on in­core inode – Converted to and from on­disk xattr on demand – Modified when xattr changed from userspace
43. 01/23/09 ext3 Changes (2) • New permissions checks – Using the NFSv4 ACL API – ext3_may_delete() ­ new – ext3_may_create() ­ new – ext3_permission() – ext3_setattr() ­ needed to duplicate inode_change_ok() • Handle chmod() – Adjust ACL: call nfs4acl_chmod() from ext3_setattr() • Initialise ACL on new inodes – Call nfs4acl_inherit() from ext3_new_inode()
44. 01/23/09 XFS Changes • Broadly similar to ext3 changes – ...but more complex – same userspace interface to set and get ACLs • CONFIG_XFS_NFS4_ACL=y • On­disk superblock bit, not mount option – mkfs.xfs ­i nfs4acl ... • XFS­specific complications – Locking, layering, behaviours, sign of error code, de­crufting • chmod() is two log transactions – Change mode, then change ACL xattr – Potential consistency problems
45. 01/23/09 NFS Server Changes • Changed from old struct nfs4_acl to struct nfs4acl – Decoding an ACL from the wire – Encoding an ACL to the wire – Converting to a POSIX ACL – Converting from a POSIX ACL • Detects what ACLs the underlying fs supports – None, POSIX, NFSv4 – Using MS_POSIXACL and MS_WITHAPPEND flags – If necessary, convert to POSIX ACL on OP_SETATTR – If necessary, convert from POSIX ACL on OP_GETATTR • Knfsd has it's own wacky MAY_* constants – Needed adjusting to cater for new MAY_APPEND
46. 01/23/09 NFS Server Changes (2) • Eliminated duplicate permission checks – Unnecessary 2nd permission check for several operations – Normally harmless – But wrong answer when underlying filesystem enforces NFSv4 ACLs • Clean­ups – Minor cruftectomies – Generalised struct xdr_stream – will help with longer ACLs later • Current size limit on ACLs smallish – 1 page, ~50 ACEs – Needs complete rewrite of server and client xdr code to fix
47. 01/23/09 Newpynfs Changes • Python­based test suite for NFSv4 – Tests server ACL behaviour at protocol level – i.e. independently of NFS client code • Extended infrastructure – ACL utilities – Multiple users, for testing ACL enforcement (reads passwd, group files) • Added interpreter for Andreas' test language – Run same test input as userspace/syscall tests, but remotely • Added various other tests
48. 01/23/09 NFS Client Changes • Caching of ACLs – ACLs are enforced on the server only – Was cached in binary XDR (on the wire) form, never interpreted – Now parsed when fetched & cached as struct nfs4acl – Implies both server and client now do idmapping on get/set • Xattr interface to userspace – Was “system.nfs4_acl” containing binary XDR form – Now “system.nfs4acl” containing same binary form as XFS, ext3 – Now can use the same userspace utility on both client and server
49. 01/23/09 NFSv4 ACL Userspace code • Userspace API libnfs4acl.a – Basically just a userspace version of the kernel API – Same structures, functions – Missing some things only need in kernel, like nfs4acl_permission() • Commandline utility /usr/sbin/nfs4acl – Get and print ACL from file(s) – Set ACL to file(s) • Test suite – basically shell­script like
50. 01/23/09 Samba Changes • New VFS module “linux_nfs4acl” – Based on ZFS ACL module – Intercepts get ACL and set ACL operations – Uses ACL API to get and set ACLs on files – Converts between the two forms – Unlike NFSv4, the CIFS protocol supports per­ACL flags
51. 01/23/09 Project Status • Due to SGI organisational changes in December 2008, this project is on indefinite hold. • Mostly­working patches and code available, all GPL • See project website for more detail
52. 01/23/09 Future Work • No idea who will do this – see Project Status • Shepherd the code into upstream • NFS server, client need to allow larger ACLs • Commandline utility needs to do Automatic Inheritance – i.e. equivalent of chmod ­R • XFS needs to provide new log transactions for safety – “Create with EA” – “Change EA and Mode” • Implement Audit features • Implement the proposed file_masks attribute
53. 01/23/09 Gnarly Issues: NFSv4 ACLs vs POSIX • ACE4_SYNCHRONIZE access bit – obviously makes no sense on POSIX • ACE4_{READ,WRITE}_NAMED_ATTR access bits – make no sense either, but rather less obviously! • Preserving more obscure corners of POSIX behaviour – Sticky bit. CAP_FOWNER, CAP_CHOWN. Restricted_chown. • Doing chmod right: file_masks and the protocol • EVERYONE@ != POSIX Other class – Far too easy to forget • Other whos (INTERACTIVE@ etc) – Make no sense in NFS context; preserved but ignored
54. 01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea
55. 01/23/09 Installing • Currently not for the faint of heart – None but the brave deserve the ACLs • Apply kernel patches to kernel, build, reboot • Install userspace RPM • Apply Samba patches, build • Enable NFSv4 ACLs on a filesystem – ext3: add acl=nfs4 option to /etc/fstab – XFS: rebuild filesystem with mkfs.xfs ­i nfs4acl • Restart NFS server, Samba
56. 01/23/09 ACL Text Representation • List of ACEs, separated by whitespace • Each ACE is four fields separated by colons – who:access­mask:flags:type – e.g. accounts:rwax:g:allow • Access mask – 1­char abbrevs, any order – r = read_data/list_directory, w = write_data/add_file – a = append_data/add_subdirectory, x = execute / traverse_directory, etc etc • Flags – 1­char abbrevs, any order – g = who field names a group • Type – allow, deny
57. 01/23/09 Example: Get An ACL $ ls -l myfile -rw-rw-r-- 1 me us 0 2008-12-10 10:03 myfile $ nfs4acl --get myfile myfile: 'r' = read_data, 'w' = write_data owner@:rw::allow group@:rw::allow everyone@:r::allow who access flags type
58. 01/23/09 Example: Set An ACL • Approx. equivalent of chmod 664 myfile $ nfs4acl --set ' owner@:rw::allow group@:rw::allow everyone@:r::allow' myfile
59. 01/23/09 Example: Remove An ACL $ nfs4acl --get myfile myfile: owner@:rw::allow group@:rw::allow everyone@:r::allow $ nfs4acl --remove myfile $ nfs4acl --get myfile myfile:
60. 01/23/09 Example: ACL From The First Slide • “all the people in Accounts can read this file, and the Auditors can read this file, and Fred can write it, but nobody else can read or write it” $ nfs4acl --get myfile myfile: 'g' => accounts is a group accounts:r:g:allow auditors:r:g:allow fred:w::allow no everyone@ entry
61. 01/23/09 Example: Fine Grain Access Control • A directory where Fred can create files but not directories, and Jane can create directories but not files. $ nfs4acl --set ' 'w' = create a file in mydir fred:rwx::allow jane:rax::allow' mydir 'a' = create a subdir in mydir
62. 01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea
63. 01/23/09 Resources • http://oss.sgi.com/projects/nfs/nfs4acl – Website • • <v4acls­external@els.sgi.com> – Mailing list • • #v4acls at irc.freenode.net – IRC channel
64. 01/23/09 References • Andreas Grünbacher, Native NFSv4 Access Control Lists on Linux, LCA2007 • Andreas Grünbacher, NFSv4 ACLs in POSIX • Andreas Grünbacher, J. Bruce Fields, NFSv4 file_masks Attribute • IBM Corp., GPFS 3.1 Adminstration and Programming Reference • Sun Microsystems Corp., Solaris ZFS Administration Guide • Microsoft Corp., How Security Identifiers Work • Microsoft Corp., How Security Descriptors and Access Control Lists Work • Undocumented NT Internals website • RFC3530: Network File System (NFS) version 4 • NFS Version 4 Minor Version 1, draft 29 • What could have been IEEE 1003.1e/2c
65. 01/23/09 Thanks • Andreas Grünbacher for being so clever • Andreas' boss for being so understanding • SGI for paying us to do this • The now ex­SGI team who worked on this project – David Disseldorp, Donald Douwsma, Barry Naujok, Tim Shimmin, Mark Goodwin • Casey Schaufler for the POSIX ACLs draft standard • Microsoft for making interoperability so challenging
66. 01/23/09 Q & A • Questions? • Stunned silence? • Job offers ?
67. 01/23/09 Extra Matter Stop Now!
68. 01/23/09 CreatorOwner, CreatorGroup • Earlier I kinda implied that Windows' CreatorOwner SID is the same as NFSv4 OWNER@ who. Not actually true! • CreatorOwner, CreatorGroup – Expanded by Windows when an ACE is inherited – Never actually seen on real ACEs – Real ACLs use the actual SID of the owner • OWNER@, GROUP@ – Expanded by NFSv4 servers when an ACE is evaluated – Commonly seen on real ACEs – Very similar to the traditional POSIX Owner, Group classes
69. 01/23/09 Automatic Inheritance • The Holy Roman Empire is neither Holy, nor Roman, nor an Empire – Voltaire
70. 01/23/09 Automatic Inheritance • The Holy Roman Empire is neither Holy, nor Roman, nor an Empire – Voltaire • Automatic Inheritance is neither automatic, nor inheritance • Actually semi­manual propagation – Userspace utility walks a tree, calculating and applying new ACLs – With NFSv4, that utility runs on the NFS client – i.e. equivalent of chmod ­R • Some ACE and ACL flags needed – To help the utility provide “sensible” behaviour – Unlike chmod ­R it's not conceptually simple – Some ACEs are inherited, some are propagated, some not....ARGH!
71. 01/23/09 Why Do It In The Filesystem? • ...why not in userspace in Samba? • To prevent remote end­runs around ACL enforcement – ftpd – rsyncd – sshd – knfsd • Need ACLs to be enforced for all local applications – Including in­kernel ones like knfsd • Sure, you could disable all those services – But what kind of a fileserver would that be? – If you want a real fileserver product, you need kernel enforcement of ACLs
72. 01/23/09 Why Not Use LSMs? • LSMs are for new security models, right? • No – they're restrictive not authoritative – An LSM cannot grant more access than the builtin Linux checks – An LSM cannot replace builtin Linux checks – This is a very deliberate and arguably sensible design choice • No – they're singletons – There is exactly one LSM active at a time – So could not have NFSv4 ACLs and SE/Linux or AppArmor at the same time – Could be fixed with the mythical stackable LSMs...? • No – they're global not per­filesystem – An NFSv4 LSM would need to be per­filesystem
73. 01/23/09 Do NFSv4 ACLs work with SE/Linux ? • ...or AppArmor, or Smack? • Maybe! – Designed to work together with these – But not tested – Would be fascinated to hear of anyone trying it?
74. 01/23/09 ACE4_READ_NAMED_ATTRS • This is a sad & confusing story • The Windows filesystem model has a lot of features – Basic boring attributes – roughly POSIX struct stat64 – Several more interesting attribute structs – mostly no POSIX equivalent – File data – large binary streams – Extended Attributes – POSIX xattrs, i.e. small named binary blobs – Alternate Data Streams – large named binary streams, no POSIX equivalent • The Windows security model has 3 “Read”­like access bits – ReadAttributes controls reading of the basic attributes – ReadExtendedAttributes controls reading the more interesting attributes – ReadData controls controls all the other three – ...approximately...
75. 01/23/09 ACE4_READ_NAMED_ATTRS (2) • Then the NFSv4 RFC has... – Named Attributes which are (unobviously) Windows ADSs – No real xattrs at all – ACE4_READ_NAMED_ATTRS access bit which controls reading Named Attrs • And POSIX has... – No ADSs – Xattrs which are the same as Windows EAs – Read 'r' access bit controls reading file data, xattrs • So...what to do with ACE4_READ_NAMED_ATTRS? – Store it and ignore it!
76. 01/23/09 ACLs and Identifying Users • NFSv4 on­the­wire form uses strings: fred@example.com • Encoded xattr form uses local UIDs: 16345 • These are stored on disk, like the inodes' owner – Need to be a permanent UID, not a temporary mapping – Which makes interoperating with Windows CIFS clients...fun • These are mapped back and forth on get/set, on both ends – Load on the idmapper – potential performance issue – Things break badly if the idmapper cannot find a mapping • The id mapping does not need to be consistent between the client and server.
77. 01/23/09 NFSv4 ACCESS op • NFSv4 has an operation called ACCESS • Identical to the NFSv3 ACCESS call – Designed to be used by the client to ask the server to do an access check • But the access bit masks make no sense – Little relationship to POSIX – Or to the NFSv4 ACL model either ?!?? – Fundamentally broken