There is, however, a much more flexible solution that you can manage yourself. Our file systems support ACLs (Access Control Lists), which you can manage with the commands “getfacl” and “setfacl”. What ACLs allow you to do is specify arbitrarily-fine-grained access control on a per-file or per-directory basis. So you could give, say, ravi and kumar “rwx” access to the file, but deny access to everybody else without ravi and kumar being in any Unix groups together.
In the 1990s the ACL and RBAC models were extensively tested and used to administrate file permissions. A filesystem ACL is a data structure (usually a table) containing entries that specify individual user or group rights to specific system objects such as programs, processes, or files. These entries are known as access control entries (ACEs) in the Microsoft Windows NT, OpenVMS, Unix-like, and Mac OS X operating systems. Each accessible object contains an identifier to its ACL. The privileges or permissions determine specific access rights, such as whether a user can read from, write to, or execute an object. In some implementations, an ACE can control whether or not a user, or group of users, may alter the ACL on an object.
Most of the Unix and Unix-like operating systems (e.g. Linux, BSD, or Solaris) support POSIX.1e ACLs, based on an early POSIX draft that was withdrawn in 1997. Many of them, for example AIX, FreeBSD, Mac OS X beginning with version 10.4 (“Tiger”), or Solaris with ZFS filesystem, support NFSv4 ACLs, which are part of the NFSv4 standard. There are two experimental implementations of NFSv4 ACLs for Linux: NFSv4 ACLs support for Ext3 filesystem and recent Richacls, which brings NFSv4 ACLs support for Ext4 filesystem.