|Front | Info | Lists | Newsfeeds | Study Guide | What is BSD?|
This is the BSDA Study Guide Book written via a wiki collaboration. This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/View_and_modify_ACLs.html.
Be able to determine if a FreeBSD system is using ACLs, and if so, on which filesystems. In addition, be able to view a file's ACL on a FreeBSD system.
ACLs provide an extended set of permissions for a file or directory. These permissions can be used in addition to the conventional UNIX permissions for files and directories. Standard UNIX file permissions (covered in section View file permissions and modify them using either symbolic or octal mode) provide read, write and execute access to three user classes:
ACLs are used to provide greater data access control for each file or directory. They enable you to define permissions for specific users and groups.
Every ACL has the following syntax:
ACL tag is a scope of the file permissions to the owner, group, others, specific users, specific groups or ACL's mask.
The ACL qualifier field describes the user or group associated with the ACL entry. It might be UID or user's name, GID or group's name, or empty.
Access permissions are the effective permissions for [ACL tag] and are specified as:
u::perm permissions for the file owner g::perm permissions for the file group o::perm permissions for the others u:UID:perm permissions for the specific user identified by UID u:username:perm permissions for the specific user identified by username g:GID:perm permissions for the specific group identified by GID g:groupname:perm permissions for the specific group identified by groupname m::perm maximum effective permissions allowed for specific users or groups.
ACLs are part of UFS2 filesystem shipped with FreeBSD 5.0-RELEASE as an option or FreeBSD 5.1-RELEASE as the default filesystem during the installation. To check which filesystem you have on your system type:
You must have ACL support compiled into the kernel too.
to your kernel config compile and install a new kernel according to the instructions in the June 2003 Answerman column.
To enable ACLs on a partition, after newfs(1)'ing it issue the commands:
This indicates that soft-updates and acls are enabled on the /dev/da1s1e partition mounted under /mountpoint.
The other way to check if ACLs are enabled is to use tunefs(1) command:
Before I show some examples please read the manpage for getfacl(1). The commands and their output below are separated by one empty line for clarity. On my test system I have a user called acl and he belongs to wheel group. When you see touch(1) command in an example, that means I recreated a file after it was removed.
Create an empty file:
The file.txt is a normal file without any ACL permissions set yet.
TODO: need to clean this part up (and others with setfacl) and just show your own possible examples without using setfacl in this doc. TODO: it would be good for beginning admin to know that setfacl exists and what it is, but according to the BSD Certification Group, TODO: this doesn't need to target modifying ACLs.
The little "+" at the end of access rights column indicates that the file has ACL set.
This command shows that owner has read/write access, group has read access, and user gregory has read/write access. I have to point now that the mask indicates the maximum permissions for user gregory.
If the command was (set the mask - "m::r"):
TODO: remove setfacl from this beginning article:
user gregory would have read/write access, but the mask would downgrade the effective access rights to read only.
There is an "-M" switch that is used to set and modify the ACL entries. The information about actual ACLs are kept in a file (in this example acls.txt).
Create acls.txt file which looks like:
In the last example ACL entry for user bin was specified in a file acls.txt. Recalculating an ACL mask
The ACLs look as above (the last getfacl(1) command), issue a command:
Now, users gregory and bin have read/write access, and the mask has been "group" ACL entries in the resulting ACL.
If the last command was:
the mask would not get recalculated (switch -n). Effective rights for users gregory and bin would be read only. Deleting an ACL
To delete an ACL entry for user bin do:
The entry for user bin was deleted. If you want the mask not to get recalculated, remember to use the "-n" switch. If you didn't use it, the mask would be read/write now, effectively changing permissions for user gregory to read/write.
To remove permanently ACL from a file issue:
Compare the above with that:
In the next example, setfacl(1) command is able to change permissions for all user classes - owner, group, others.
More interesting example:
The last setfacl(1) command set the access rights as follows:
Then I changed explicitly access rights with chmod(1) command:
and the access rights reapeared as:
Note, the mask is closely associated with group access rights. Changing Unix access rights with chmod(1), you also change the mask value.
Consider this scenario:
Changing the mask value, does change group access rights.
If you see a file with a magic "+" at the end of access rights column, check it with getfacl(1). Copying ACL entries
Creating default ACLs
Default ACL entries provide a way to propagate ACL information automatically to files and directories. New files and directories inherit ACL information from their parent directory if that parent has an ACL that contains default entries. You can set default ACL entries only on directories.
Before you set any default ACL entries for users or groups, you must set default ACL entries for owner, group, other, and ACL mask.
The correct order is:
To view default ACLs issue getfacl(1) with the "-d" switch.
To see the effect of default ACLs on subdirectories issue the following commands:
The subdir directory successfully inherited default ACL entries from its parent.
Suppose, you want to set default ACL entries for additional user bin:
That new default ACL entries for addtional user bin are not visible on dir/subdir as the directory was created before the ACL entry for bin was set.
To see the effect of default ACLs on files, create a file beneath the dir directory:
The setfacl(1) manual states: "Currently only directories may have default ACL's. Deleting default ACLs
To delete default ACLs on directories, use setfacl(1) with the "-k" switch:
To delete a default ACL entry for user bin do:
Create acls.txt file which looks like:
or simply type:
Things to remember
setfacl(1) always recalculates the ACL mask to allow maximum effective permissions for every ACL entry, unless the "-n" switch is used.
If you use the chmod(1) command to change the file group owner permissions on a file with ACL entries, both the file group owner permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions may change the effective permissions for additional users and groups who have ACL entries on the file.
mount(8), ls(1), getfacl(1)