Managing NFS and NIS, 2nd Edition - Mike Eisler [153]
user::rwx
user:linus:rwx
user:sally:rwx
group::---
mask:rwx
other:---
default:user::rwx
default:user:linus:rwx
default:user:sally:rwx
default:group::---
default:mask:rwx
default:other:---
It is the default: entries that result in inherited ACLs. The reason why we add execution permissions is so that directories have search permissions, i.e., so lucy and her cohorts can change their current working directories to her protected directories.
Once you've got default ACLs set up for various groups of users, you then apply it to each top-level directory that you create:
% mkdir lucystuff
% setfacl -f /home/lucy/acl.default lucystuff
Note that you cannot apply an ACL file with default: entries in it to nondirectories. You'll have to create another file without the default: entries to use setfacl -f on nondirectories:
% grep -v '^default:' | /home/lucy/acl.default > /home/lucy/acl.files
The preceding example strips out the default: entries. However it leaves the executable bit on in the entries:
% cat /home/lucy/acl.files
user::rwx
user:linus:rwx
user:sally:rwx
group::---
mask:rwx
other:---
This might not be desirable for setting an ACL on existing regular files that don't have the executable bit. So we create a third ACL file:
% sed 's/x$/-/' /home/lucy/acl.files | sed 's/^mask.*$/mask:rwx/' \
> /home/lucy/acl.noxfiles
This first turns off every execute permission bit, but then sets the mask to allow execute permission should we later decide to enable execute permission on a file:
% cat /home/lucy/acl.noxfiles
user::rw-
user:linus:rw-
user:sally:rw-
group::---
mask:rwx
other:---
With an ACL file with default: entries, and the two ACL files without default: entries, lucy can add protection to existing trees of files. In the following example, oldstuff is an existing directory containing a hierarchy of files and subdirectories:
fix the directories:
% find oldstuff -type d -exec setfacl -f /home/lucy/acl.default {} \;
fix the nonexecutable files:
% find oldstuff ! -type d ! ( -perm -u=x -o -perm -g=x -o -perm -o=x ) \
-exec setfacl -f /home/lucy/acl.noxfiles {} \;
fix the executable files:
% find oldstuff ! -type d ( -perm -u=x -o -perm -g=x -o -perm -o=x ) \
-exec setfacl -f /home/lucy/acl.noxfiles {} \;
In addition to solving the "too many groups in NFS" problem, another advantage of ACLs versus groups is potential decentralization. As the system administrator, you are called on constantly to add groups, or to modify existing groups (add or delete users from groups). With ACLs, users can effectively administer their own groups. It is a shame that constructing ACLs is so arcane, because it effectively eliminates a way to decentralize a security access control for logical groups of users. You might want to create template ACL files and scripts for setting them to make it easier for your users to use them as a way to wean them off of groups. If you succeed, you'll reduce your workload and deal with fewer issues of "too many groups in NFS."
* * *
Tip
In Solaris, ACLs are not preserved when copying a file from the local ufs filesystem to a file in the tmpfs (/tmp) filesystem. This can be a problem if you later copy the file back from /tmp to a ufs filesystem. Also, in Solaris, ACLs are not, by default, preserved when generating tar or cpio archives. You need to use the -p option to tar to preserve ACLs when creating and restoring a tar archive. You need to use the -P option to cpio when creating and restoring cpio archives. Be aware