Richacls are an implementation of NFSv4 ACLs which has been extended by file masks to better fit the standard POSIX file permission model. The main goal is to provide a consistent file permission model locally as well as over various remote file system protocols like NFSv4 and CIFS; this is expected to significantly improve interoperability in mixed operating system environments, both when Linux is used as a client and as a server.
Richacls share some design elements with POSIX ACLs, but they go beyond POSIX ACLs in several ways. Converting from POSIX ACLs to richacls is relatively easy, but converting back from richacls to POSIX ACLs is not possible without losing information.
Richacls can be enabled for an entire file system. Once enabled, that file system supports richacls instead of POSIX ACLs; a file system never supports both models at the same time.
Richacls exist in the form of out-of-tree patches for the Linux kernel, a user-space utility for getting and setting richacls, and changes to the coreutils package for richacl support in the ls and cp utilities. The kernel patches currently include experimental support for the ext4, nfs, and nfsd file systems.
Code for supporting richacls in samba, xfs, and newpynfs exists, but more work is needed in those areas.
|coreutils + gnulib||
The richacl package includes the following manual pages:
The design of richacls is documented in NFSv4 ACLs in POSIX. This design dates back to 2006, and has already been implemented in nfs4acls, the predecessor project of richacls.
Richacls have been presented at the Ottawa Linux Symposium 2010 by Greg Banks (link to the presentation slot). Greg's publications list includes the conference paper and slides he has used under the heading “Implementing An Advanced Access Control Security Model in Linux”.
The POSIX 1003.1e / 1003.2c draft 17 documents which describe POSIX ACLs, which have influenced the richacl design, can be found here. An overview of POSIX ACLs on Linux can be found here).
Copyright (C) Andreas Grünbacher <firstname.lastname@example.org>, January 2016