ACLs
From Linux NFS
| Line 53: | Line 53: | ||
== ACL models == | == ACL models == | ||
| - | === NFSv4 and Windows ACLs == | + | === NFSv4 and Windows ACLs === |
NFSv4 ACLs are documented by section 5.11 of [http://www.ietf.org/rfc/rfc3530.txt rfc3530]. See [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp msdn] for Windows ACL documentation. | NFSv4 ACLs are documented by section 5.11 of [http://www.ietf.org/rfc/rfc3530.txt rfc3530]. See [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp msdn] for Windows ACL documentation. | ||
| Line 72: | Line 72: | ||
As noted above, these aren't really POSIX, though they've been implemented on lots of operating systems, including Solaris and Linux. See the [http://wt.xpilot.org/publications/posix.1e/download.html POSIX draft] for detailed documentation. | As noted above, these aren't really POSIX, though they've been implemented on lots of operating systems, including Solaris and Linux. See the [http://wt.xpilot.org/publications/posix.1e/download.html POSIX draft] for detailed documentation. | ||
| - | The range of access controls specifiable by POSIX ACLs is more limited than that of Windows/NFSv4 ACLs, so (see the [http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-03.txt POSIX<->NFSv4 mapping draft]) | + | The range of access controls specifiable by POSIX ACLs is more limited than that of Windows/NFSv4 ACLs, so it is possible to map any POSIX ACL to an NFSv4 ACL with the same semantics (see the [http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-03.txt POSIX<->NFSv4 mapping draft]), but the reverse is not true. |
The popularity and flexibility of Windows/NFSv4 ACLs makes it tempting to just ignore POSIX ACLs. However, | The popularity and flexibility of Windows/NFSv4 ACLs makes it tempting to just ignore POSIX ACLs. However, | ||
| - | * The flexibility of Windows ACL's could make them harder to use them correctly. People with experience suggested that in practice users do have trouble. (Any references to published evidence here would be useful. (E.g., [http://www.cs.princeton.edu/~sudhakar/papers/winval.pdf ] | + | * The flexibility of Windows ACL's could make them harder to use them correctly. People with experience suggested that in practice users do have trouble. (Any references to published evidence here would be useful. (E.g., [http://www.cs.princeton.edu/~sudhakar/papers/winval.pdf Windows Access Control Demystified] studies ACL misconfiguration problems, though the specific problems identified seem to be with access bits not relevant to file system permissions.) |
| - | + | ||
* POSIX ACL's are what are currently available on Linux and some other platforms, so we can expect that they are what developers are currently coding to; thus even if they aren't widely used now, they may be in a few years (by which time file managers have built-in support for them, etc.). | * POSIX ACL's are what are currently available on Linux and some other platforms, so we can expect that they are what developers are currently coding to; thus even if they aren't widely used now, they may be in a few years (by which time file managers have built-in support for them, etc.). | ||
Revision as of 22:19, 10 March 2006
Contents |
Introduction to NFSv4 ACLs
Some NFSv2 and v3 implementations support ACLs based on POSIX draft ACLs which depend on a searate rpc program (instead of being part of the NFS protocol itself).
The NFSv4 protocol includes integrated support for ACLs which are similar to those used by Windows. NFSv4 ACLs are richer than POSIX draft ACLs--any POSIX ACL can be represented by an NFSv4 ACL with almost the same semantics, whereas the reverse is not true.
Useful references:
- rfc3530 (especially section 5.11)]
- POSIX draft ACLs: POSIX ACLs aren't really POSIX--they were never accepted--but some variation of them is implemented on many operating systems, including Linux.
- The Linux man pages, specifically, acl(5), setfacl(1), getfacl(1), and setxattr(2).
- The POSIX<->NFSv4 mapping draft, which explains how we map between POSIX and NFSv4 ACLs.
- The CITI NFSv4 project page, which has links to modified linux acl utilities with preliminary NFSv4 support
- draft-falkner-nfsv4-acls-00.txt, which suggests some clarifications to the NFSv4 ACL specification, and addresses some issues for NFSv4 implementors on UNIXy systems, including, for example, details on interactions with chmod.
Design of the linux NFSv4 ACL implementation
Server
None of the filesystems which the linux server exports support NFSv4 ACLs. However, many of them do support POSIX ACLs. So we map NFSv4 ACLs to POSIX ACLs and store POSIX ACLs in the filesystem. The mapping is imperfect, and prevents the server from accepting the full range of NFSv4 ACLs. We could instead store NFSv4 ACLs somewhere else--say in a separate extended attribute used only by the NFSv4 server. However, this would prevent our ACLs from being enforced against local users of the same filesystem. The code to perform this mapping on the server side is in the kernel, in fs/nfsd/nfs4acl.c.
Client
The client can also map between NFSv4 and POSIX ACLs, to allow it to support existing POSIX ACL interfaces. However it does this mapping in userspace; the kernel deals only in NFSv4 ACLs, which it exposes through a special extended attribute ("system.nfs4_acl"). Applications that use the POSIX ACL interfaces need to use a version of libacl that has been modified to do POSIX<->NFSv4 ACL mapping. But since userspace also has full access to the raw NFSv4 ACL, we can also provide utilities that get and set NFSv4 ACLs directly, without the need for mapping.
The data in the system.nfs4_acl attribute consists of the raw xdr data which the client receives from the server as the value of the "acl" attribute. It is up to userspace to do xdr decoding and encoding.
The ACL Interoperability Problem
We now have three ACL models to deal with: NFSv4, Windows, and "POSIX ACLs"/mode bits. And we have to decide what to do with them all in the face of existing users, tools, and system interfaces that assume one or the other.
More specifically:
A server has to store ACL's persistently on its filesystem. There are immense advantages to storing those ACL's using whatever ACL's the filesystem and operating system support, because that will ensure that they are automatically enforced against other applications and protocol services using the same filesystem.
Some servers are therefore translating to and from their native format. Others are implementing NFSv4 ACL's in the filesystem.
The client in theory has a simpler problem--it can always provide its own application for manipulating ACLs. However:
- Some applications (Microsoft Word was mentioned as one) manipulate ACL's directly (on temporary files? Examples might be useful here.)
- Users may have experience with existing ACL models and tools, which may be better integrated into important tools (like Microsoft Explorer)
- Administrators may have built up scripts that manipulate or check ACL's.
For this reason client implementers may have to deal with non-NFSv4 ACL's as well.
ACL models
NFSv4 and Windows ACLs
NFSv4 ACLs are documented by section 5.11 of rfc3530. See msdn for Windows ACL documentation.
The two ACL models are essentially the same, with some minor differences:
- RFC3530 says that if an ACL neither allows nor denies a certain mode bit, then behavior is undefined. But users of Windows ACLs expect them to deny by default.
- Windows documentation suggests that if some but not all requested access bits have been allowed, then DENY aces will still apply even if they only deny bits among those already allowed. This has the somewhat bizarre result that an ACL can allow certain permissions individually but deny them in combination. The NFSv4 ACL algorithm doesn't have this property.
A bigger (and perhaps more important!) difference is in the names, which we're ignoring for now.
The new OSX ACLs seem to be essentially identical to Windows ACLs.
We know of no concerted effort to implement NFSv4/Windows ACLs on Linux filesystems, but Solaris and AIX also both seem to be adding support for NFSv4 ACLs. Two Sun developers have an internet draft draft-falkner-nfsv4-acls-00.txt which proposes more precise semantics for NFSv4 ACLs and deals with mode-bit mapping and other issues of particular interest for NFSv4 ACL implementors on POSIX systems.
POSIX ACLs
As noted above, these aren't really POSIX, though they've been implemented on lots of operating systems, including Solaris and Linux. See the POSIX draft for detailed documentation.
The range of access controls specifiable by POSIX ACLs is more limited than that of Windows/NFSv4 ACLs, so it is possible to map any POSIX ACL to an NFSv4 ACL with the same semantics (see the POSIX<->NFSv4 mapping draft), but the reverse is not true.
The popularity and flexibility of Windows/NFSv4 ACLs makes it tempting to just ignore POSIX ACLs. However,
- The flexibility of Windows ACL's could make them harder to use them correctly. People with experience suggested that in practice users do have trouble. (Any references to published evidence here would be useful. (E.g., Windows Access Control Demystified studies ACL misconfiguration problems, though the specific problems identified seem to be with access bits not relevant to file system permissions.)
- POSIX ACL's are what are currently available on Linux and some other platforms, so we can expect that they are what developers are currently coding to; thus even if they aren't widely used now, they may be in a few years (by which time file managers have built-in support for them, etc.).
