Using Extended Filesystem Access Control List

Home / Using Extended Filesystem Access Control List

Using Extended Filesystem Access Control List

December 9, 2015 | Article | No Comments

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.

In earlier article, we have discussed about simple permission on UNIX Operating System. In this article we will discuss about using Extended Access Control List on Filesystem for permission. In this article I use:

  1. Slackware64 14.0
  2. XFS

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?

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.

The Classes

Generally, Extended-ACL defines six classes of entry, instead of well-known three class as in traditional permission system. They are:

Entry type Text Form
Owner user::rwx
Named user user:name:rwx
Owning group group::rwx
Named group group:name:rwx
Mask mask::rwx
Others other::rwx

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
user::rwx
group::r-x
other::---

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
user::rwx
user:marina:rw
group::r-x
mask::rwx
other::---

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
user::rwx
user:marina:rwx
user:elisa:r--
group::r-x
mask::rwx
other::---

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

Yes, as simple as that 😀

, , ,

About Author

about author

xathrya

A man who is obsessed to low level technology.

Leave a Reply

Your email address will not be published. Required fields are marked *

Social media & sharing icons powered by UltimatelySocial