Access Control List, or ACL, is a simple security mechanism but most likely implemented on any system. Not to mention, it is also implemented on various filesystem, including ext2, ext3, ext4 and also XFS.
If in earlier article we have discussed about Extended ACL in general, now we will discuss about Access Control List specific on UFS, which used by FreeBSD.
In this article I use:
- FreeBSD amd64 8.3
ACL and POSIX
As seen on this article, traditional POSIX file system object permission model defines three classes of users: owner, group, and other. Each of these classes is associated with a set of permission.
The owner class permissions define access privileges to the object (file/folder) owner. The group refers to the owning groups and thus the group permissions defines action can be done by owning group of file. When a user is not either owner or group owner of file, s/he simply referred as other and having other permissions on the file.
The permissions are defined as read, write, and execute an object and denote as r, w, x.
An Extended-ACL consists of a set of entries. The permissions of each file system object have an ACL representation, even in the minimal. On traditional ACL, there are owner, group, and other permissions. One for each class. In Extended ACL, every class might has one or more entries defined. In ACL, default permission entries are calle minimal ACL.
Extended-ACL also contain a mask entry and may contain any number of named. user and named group entries.
So what makes Extended-ACL good? Let’s use same case as used in this article.
Extended-ACL can control permission in detail. Using Extended-ACL we can specify what user can do, or what group can do.
Let take an example of this. Let say there are three user: xathrya, marina, and elisa. All of them are on group developer. A file “secret.txt” is created and owned by xathrya. Xathrya want to restrict marina from reading the file, while elisa is restricted to writing the file. Then there is no restriction for marina to write file and elisa to read the file. Using file permission, xathrya can set the permission to 760 so only him can alter the file. But as a fellow group member, marina and elisa can also alter the file. If xathrya alter the file permission to 740, elisa is restricted from writing the file but marina is not restricted to reading. If xathrya use 720, the other condition applies.
Using Extended-ACL, xathrya can precisely set restriction on marina and elise. On account marina, xathrya can put ban for her to read while he can also put ban for elise to write. So that we can have permission -w- specific to marina and r– for elisa. This is the power of Extended-ACL.
ACL extend the standard UNIX permission model in a higly compatible POSIX way. But to enable ACL support for UFS file system we must make sure kernel is capable to do so. You might also recompile the kernel if you don’t have enable the support yet. When you are recompiling, make sure you enable
If this option has note been compiled in, a warning message will be displayed when attempting to mount a file system supporting ACLs. This option is included in the GENERIC kernel and is relied upon when using extended attributes.
A file / directory with ACL will show a + (plus) sign in their permission settings when viewed. For example:
drwx------ 2 xathrya wheel 512 Dec 27 11:54 private
drwxrwx---+ 2 xathrya wheel 512 Dec 23 10:57 directory1
drwxrwx---+ 2 xathrya wheel 512 Dec 22 10:20 directory2
drwxrwx---+ 2 xathrya wheel 512 Dec 27 11:57 directory3
drwxr-xr-x 2 xathrya wheel 512 Nov 10 11:54 public_html
Here we see directory1, directory2, and directory3 are taking advantage of ACLs while public_heml directory is not.
Generally, Extended-ACL defines six classes of entry, instead of well-known three class as in traditional permission system. They are:
As seen there, what is mask? Before we discuss that, let’s get deeper into new class named user and named group.
Named group and named user entries are assigned to the group class, which already contains the owning group entry. Different from the traditional permission model, the group class may now contain ACL entries with different permission sets, so the group class permissions alone are no longer sufficient to represent all the detailed permissions of all ACL entries it contains.
Well, let say that on earlier model, all group user are bound together using group permission. So one permission will be applied to all of group member. However in Extended-ACL, user is not bounded in that manner.
Therefore, the meaning of the group class permissions is redefined: under their new semantics, they represent an upper bound of the permissions that any entry in the group class will grant.
This upper bound property ensures that POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported.
In minimal ACLs (traditional), the group class permissions are identical to the owning group permissions. In Extended-ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.
This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With Extended-ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant.
Dive into Extended-ACL
On default, for every file creation a standard traditional permission model is used to “stamp” files. We can set Extended-ACL later.
Now, let’s start by cerating a directory and checking its permission. The umask determines which permissions will be masked off then the directory is created. A umask 027 disables write access for the owning group; and read,write,execute access for others.
$ umask 027
$ mkdir dir
$ ls -dl dir
drwxr-x--- ... xathrya users ... dir
The string “rwxr-x--” represents the resulting permissions for the new directory: read, write, and execute access for the owner and read and execute access for the owning group. The dots in the output of ls stand for text that is not relevant here and has been removed.
These base permissions have an equivalent representation as an ACL. ACLs are displayed using the getfacl command.
$ getfacl dir
# file: dir
# owner: xathrya
# group: users
The first three lines of output contain the file name, owner, and owning group of the file as comments. Each of the following lines contains an ACL entry for one of the three classes of users: owner, group, and other. And that is a traditional permission model.
Now we will grants read, write access to user Marina in addition to the existing permissions. For that, the -m (modify) argument of setfacl is used. The resulting ACL is again shown using the getfacl command. The -omit-header option to getfacl suppresses the three-line comment header containing the file name, owner, and owning group to shorten the examples shown.
$ setfacl -m user:marina:rw dir
$ getfacl --omit-header dir
Two additional entries have been added to the ACL: one is for user Marina and the other is the mask entry. The mask entry is automatically created when needed but not provided. Its permissions are set to the union of the permissions of all entries that are in the group class, so the mask entry does not mask any permissions.
Now, to grant only read permission to Elisa, we can also do:
$ setfacl -m user:elisa:r-- dir
$ getfacl --omit-header dir
Now, let see what these commands (one line per command) will do:
setfacl -d -m group:developer:r-x tools
setfacl -m user:root:--- supersecret.txt
setfacl -m user:marina:r-- file.txt
Now, how to remove an ACL entry from a file? There is a simple command to do so. For example, we want to lift ban from Marina on file.txt then we invoke following:
setfacl -x user:marina file.txt