Tweet
Tweet

Slide 1

Slide 1 text

Headline in Arial Bold 30pt Implementing Native NFSv4 ACLs in Linux Greg Banks Principal Engineer Silicon Graphics, Inc.

Slide 2

Slide 2 text

01/23/09 Slide 2 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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”

Slide 5

Slide 5 text

01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea

Slide 6

Slide 6 text

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)

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

01/23/09 Some Access Models For Filesystems • Traditional POSIX • Draft POSIX ACLs • Windows NT ACLs • NFSv4 ACLs

Slide 9

Slide 9 text

01/23/09 Access Models...Graphically Windows ACLs Trad POSIX Draft POSIX ACLs NFSv4 ACLs

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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?

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

01/23/09 “Rich” • The NFS version 4 ACL model is quite rich – RFC 3530

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

01/23/09 Who implements NFSv4 ACLs? • ZFS from Sun • GPFS from IBM • Linux NFS server, client – kinda...

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

01/23/09 Architecture: Local Applications

Slide 35

Slide 35 text

01/23/09 Architecture: Using NFS

Slide 36

Slide 36 text

01/23/09 Architecture: Using CIFS

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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)

Slide 41

Slide 41 text

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 *)

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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()

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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:

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

01/23/09 Contents • Introduction • Access Models 101 • Why NFSv4 ACLs? • SGI NFSv4 ACL Project • Using NFSv4 ACLs • Miscellanea

Slide 63

Slide 63 text

01/23/09 Resources • http://oss.sgi.com/projects/nfs/nfs4acl – Website • • – Mailing list • • #v4acls at irc.freenode.net – IRC channel

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

01/23/09 Q & A • Questions? • Stunned silence? • Job offers ?

Slide 67

Slide 67 text

01/23/09 Extra Matter Stop Now!

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

01/23/09 Automatic Inheritance • The Holy Roman Empire is neither Holy, nor Roman, nor an Empire – Voltaire

Slide 70

Slide 70 text

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!

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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?

Slide 74

Slide 74 text

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...

Slide 75

Slide 75 text

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!

Slide 76

Slide 76 text

01/23/09 ACLs and Identifying Users • NFSv4 on­the­wire form uses strings: [email protected] • 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.

Slide 77

Slide 77 text

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