INTRODUCTION

…
The cluster administration tools like crm shell (crmsh) or Hawk2 can be used by root or any user in
the group haclient. By default, these users have full read/write access. To limit access or assign more
fine-grained access rights, you can use Access control lists (ACLs).

Access control lists consist of an ordered set of access rules. Each rule allows read or write access or
denies access to a part of the cluster configuration. Rules are typically combined to produce a specific
role, then users may be assigned to a role that matches their tasks.

POSIX ACLs (access control lists) can be used as an expansion of the traditional permission concept
for file system objects. With ACLs, permissions can be defined more flexibly than the traditional
permission concept allows.

The term POSIX ACL suggests that this is a true POSIX (portable operating system interface)
standard. The respective draft standards POSIX 1003.1e and POSIX 1003.2c have been withdrawn for
several reasons. Nevertheless, ACLs as found on many systems belonging to the UNIX family are based
on these drafts and the implementation of file system ACLs as described in this chapter follows these
two standards as well.

ADVANTAGES

Traditionally, three sets of permissions are defined for each file object on a Linux system. These sets
include the read (r), write (w), and execute (x) permissions for each of three types of users — the file
owner, the group, and other users. This scheme is implemented using only nine bits for each object .In
addition to that, it is possible to set the set user id, the set group id, and the sticky bit.

This lean concept is fully adequate for most practical cases. However, for more complex scenarios or
advanced applications, system administrators formerly had to use a number of tricks to circumvent the
limitations of the traditional permission concept.

ACLs can be used for situations that require an extension of the traditional file permission concept.
They allow assignment of permissions to individual users or groups even if these do not correspond to
the original owner or the owning group. Access control lists are a feature of the Linux kernel and are
currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS. Using ACLs, complex scenarios can be realized
without implementing complex permission models on the application level.

Although the traditional model is extremely simple, it is sufficient for implementing the permission
scenarios that usually occur on UNIX systems. System administrators have also found several
workarounds for the model's limitations. Some of these workarounds require nonobvious group setups
that may not reflect organizational structures. Only the root user can create groups or change group
membership. Set-user-ID root utilities may allow ordinary users to perform some administrative tasks,
but bugs in such utilities can easily lead to compromised systems. Some applications like FTP daemons
implement their own extensions to the file system permission model. The price of playing tricks with
permissions is an increase in complexity of the system configuration. Understanding and maintaining the
integrity of systems becomes more difficult.
 Engineers have long recognized the deficiencies of the traditional permission model and have
started to think about alternatives. This has eventually resulted in a number of Access Control List (ACL)
implementations on UNIX, which are only compatible among each other to a limited degree.

This paper gives an overview of the most successful ACL scheme for UNIX-like systems that has
resulted from the POSIX 1003.1e/1003.2c working group.

The advantages of ACLs are clearly evident in situations like the replacement of a Windows server by
a Linux server. Some of the connected workstations may continue to run under Windows even after the
migration. The Linux system offers file and print services to the Windows clients with Samba.

Given that Samba supports access control lists, user permissions can be configured both on the
Linux server and in Windows with a graphical user interface (only Windows NT and later). With
winbindd, it is even possible to assign permissions to users that only exist in the Windows domain
without any account on the Linux server. On the server side, edit the access control lists using getfacl
and setfacl.

Definitions

user class
The conventional POSIX permission concept uses three classes of users for assigning permissions in
the file system: the owner, the owning group, and other users. Three permission bits can be set for each
user class, giving permission to read (r), write (w), and execute (x).

access ACL
The user and group access permissions for all kinds of file system objects (files and directories) are
determined by means of access ACLs.

default ACL
Default ACLs can only be applied to directories. They determine the permissions a file system object
inherits from its parent directory when it is created.

ACL entry
Each ACL consists of a set of ACL entries. An ACL entry contains a type (see Table �28.1. “ACL Entry
Types”), a qualifier for the user or group to which the entry refers, and a set of permissions. For some
entry types, the qualifier for the group or users is undefined.

Handling ACLs

This section explains the basic structure of an ACL and its various characteristics. The interrelation
between ACLs and the traditional permission concept in the Linux file system is briefly demonstrated by
means of several figures. Two examples show how to create your own ACLs using the correct syntax. In
conclusion, find information about the way ACLs are interpreted by the operating system.

Structure of ACL Entries

There are two basic classes of ACLs: A minimum ACL merely comprises the entries for the types
owner, owning group, and other, which correspond to the conventional permission bits for files and
directories. An extended ACL goes beyond this. It must contain a mask entry and may contain several
entries of the named user and named group types. Figure 1 “ACL Entry Types” provides a summary of
the various types of ACL entries that are possible.

Figure 1 ACL Entry Types

The permissions defined in the entries owner and other are always effective. Except for the mask
entry, all other entries (named user, owning group, and named group) can be either effective or masked.
If permissions exist in one of the above-mentioned entries as well as in the mask, they are effective.
Permissions contained only in the mask or only in the actual entry are not effective. The example in
Figure2 . “Masking Access Permissions” demonstrates this mechanism.

Figure 2 Masking Access Permissions

Figure3 “Minimum ACL: ACL Entries Compared to Permission Bits” and Figure4 “Extended ACL: ACL
Entries Compared to Permission Bits” illustrate the two cases of a minimum ACL and an extended ACL.
The figures are structured in three blocks — the left block shows the type specifications of the ACL
entries, the center block displays an example ACL, and the right block shows the respective permission
bits according to the conventional permission concept as displayed by ls -l, for instance. In both cases,
the owner class permissions are mapped to the ACL entry owner. Equally, other class permissions are
mapped to the respective ACL entry. However, the mapping of the group class permissions is different in
the two cases.

Figure 3 Minimum ACL: ACL Entries Compared to Permission Bits

 In the case of a minimum ACL — without mask — the group class permissions are mapped to the
ACL entry owning group. This is shown in Figure3 “Minimum ACL: ACL Entries Compared to Permission
Bits”. In the case of an extended ACL — with mask — the group class permissions are mapped to the
mask entry. This is shown in Figure4. “Extended ACL: ACL Entries Compared to Permission Bits”.

This mapping approach ensures the smooth interaction of applications, regardless of whether they
have ACL support. The access permissions that were assigned by means of the permission bits represent
the upper limit for all other “fine adjustments” made by means of ACLs. Any permissions not reflected
here were either not set in the ACL or are not effective. Changes made to the permission bits are
reflected by the ACL and vice versa.

Figure 4 Extended ACL: ACL Entries Compared to Permission Bits

Use examples

How to know when a file has ACL attached to it

It is very easy to know when a file has a attached ACL to it. ls -l command would produce a output as
show below.

# ls -l
-rw-r--r-+ 1 root root 0 Sep 19 14:41 file

Note the + sign at the end of the permissions. This confirms that the file has an ACL attached to it.

Viewing ACLs

To display details ACL information of a file use the getfacl command.

# getfacl /tmp/test
# file: test
# owner: root
# group: root
user::rw-
user:john:rw-
user:sam:rwx
 group::r--
mask::rwx
other:---

Notice the 3 different user: lines. The first line lists the standard file permissions of the owner of the
file. The 2 other user permissions are the individual permission for the user john and sam. The mask field
here only applies to the additional permissions we have given to the user and groups. If the mask is set
to rwx the read, write and execute permissions will be granted to additional user/groups. If the mask is
set to r-x, the write permission will not be granted to additional user/groups.In general, DO NOT set
mask to anything other than rwx. The mask value doe not affect the standard UNIX user/group/others
permissions.

File with no ACLs

If you run the getfacl command on a file with no ACLs the additional “user:” lines and “mask” line
will not be shown and standard file permissions will be shown.

# getfacl test
# file: test
# owner: root
# group: root
user::rw-
group::r--
other::r—

Creating and Managing FACLs

The setfacl command is used to set ACL on the given file. To give a rw access to user john on the
file /tmp/test :

# setfacl -m u:john:rw /tmp/test

The -m option tells setfacl to modify ACLs on the file(s) mentioned in command line. Instead of user
john we can have a group to have a specific permission on the file :

# setfacl -m g:accounts:rw /tmp/test

FACLs for multiple user and groups can also be set with single command :

# setfacl -m u:john:rw,g:accounts:rwx /tmp/test

Default FACLs on directories

Default ACLs are only created on directories. When you set default ACLs on directories, any files
created within that directory will also have that default FACL assigned automatically.

To create a default FACL on a directory :

# setfacl -m default:u:john:rw /accounts

 # getfacl accounts/
# file: accounts/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:john:rw-
default:group::r-x
default:mask::rwx
default:other::r-x

Now create a new file in the accounts directory and list the FACL on the file :

# touch /accounts/test
# getfacl test
# file: test
# owner: root
# group: root
user::rw-
user:john:rw-
group::r-x #effective:r--
mask::rw-
other::r—

Removing FACLs

To remove FACL, use the setfacl command with -x option :

# setfacl -x u:john /tmp/test

The above command removes the ACL for the user john on the file /tmp/test. The ACLs for other
user/groups if any remains unaffected.

To remove all ACLs associated to a file use the -b option with setfacl :

# setfacl -b /tmp/test

Backing up the FACLs

Many times, the backup software may not copy the metadata related to the FACL on the files. In
that case you may want to backup the FACL information on the files. Now, the FACL on all the files in a
directory (including all sub directories) can be copied in a single file.

# cd /accounts
# getfacl -R * > accounts_facl ( -R -> recursive )

Restoring the FACLs

 When you restore the files in /accounts directory, you would have to restore the FACLs associated
with the files in that direcotry. TO do that use the FACL backup file accounts_facl along with the –
restore option :

# setfacl --restore=accounts_facl

A Directory with Access ACL

The handling of access ACLs is demonstrated in three steps by means of the following example:
 Creating a file system object (a directory in this case)
 Modifying the ACL
 Using masks

1. Before you create the directory, use the umask command to define which access permissions
should be masked each time a file object is created. The command umask 027 sets the default
permissions by giving the owner the full range of permissions (read, write, execute) (0), denying the
owning group write access (2), and giving other users no permissions at all (7). umask actually masks the
corresponding permission bits or turns them off. For details, consult the corresponding man page (man
umask).

mkdir mydir should create the mydir directory with the default permissions as set by umask. Use
the following command to check if all permissions were assigned correctly:

ls -dl mydir

drwxr-x--- ... tux project3 ... mydir

2. Check the initial state of the ACL and insert a new user entry and a new group entry with
getfacl mydir. This gives information like:

# file: mydir
# owner: tux
# group: project3
user::rwx
group::r-x
other::---

The output of getfacl precisely reflects the mapping of permission bits and ACL entries as described
in section “ACL Entries and File Mode Permission Bits”. The first three output lines display the name,
owner, and owning group of the directory. The next three lines contain the three ACL entries owner,
owning group, and other. In fact, in the case of this minimum ACL, the getfacl command does not
produce any information you could not have obtained with ls.

Your first modification of the ACL is the assignment of read, write, and execute permissions to an
additional user jane and an additional group djungle.

setfacl -m user:jane:rwx,group:djungle:rwx mydir

 The option -m prompts setfacl to modify the existing ACL. The following argument indicates the
ACL entries to modify (several entries are separated by commas). The final part specifies the name of
the directory to which these modifications should be applied. Use the getfacl command to take a look at
the resulting ACL.

getfacl mydir

# file: mydir
# owner: tux
# group: project3
user::rwx
user:jane:rwx
group::r-x
group:djungle:rwx
mask::rwx
other::---

In addition to the entries initiated for the user jane and the group djungle, a mask entry has
been generated. This mask entry is set automatically to reduce all entries in the group class to a
common denominator. Furthermore, setfacl automatically adapts existing mask entries to the settings
modified, provided you do not deactivate this feature with -n. mask defines the maximum effective
access permissions for all entries in the group class. This includes named user, named group, and
owning group. The group class permission bits that would be displayed by ls -dl mydir now
correspond to the mask entry.

ls -dl mydir d drwxrwx---+ ... tux project3 ... mydir

As expected, the group class permission bits now reflect the mask entry.The first column of the
output now contains an additional + to indicate that there is an extended ACL for this item.

3. According to the output of the ls command, the permissions for the mask entry include write
access. Traditionally, such permission bits would mean that the owning group (here project3) also
has write access to the directory mydir. However, the effective access permissions for the owning
group correspond to the overlapping portion of the permissions defined for the owning group and for
the mask — which is r-x in our example (see Figure2 “Masking Access Permissions”). As far as the
effective permissions of the owning group are concerned, nothing has changed even after the addition
of the ACL entries.

Edit the mask entry with setfacl or chmod.

chmod g-w mydir

ls -dl mydir

drwxr-x---+ ... tux project3 ... mydir

getfacl mydir
 # file: mydir
# owner: tux
# group: project3
user::rwx
user:jane:rwx # effective: r-x
group::r-x
group:djungle:rwx # effective: r-x
mask::r-x
other::---

After executing the chmod command to remove the write permission from the group class bits, the
output of the ls command is sufficient to see that the mask bits must have changed accordingly: write
permission is again limited to the owner of mydir. The output of the getfacl confirms this. This output
includes a comment for all those entries in which the effective permission bits do not correspond to the
original permissions, because they are filtered according to the mask entry. The original permissions can
be restored at any time with chmod:

chmod g+w mydir

ls -dl mydir

drwxrwx---+ ... tux project3 ... mydir

getfacl mydir

# file: mydir
# owner: tux
# group: project3
user::rwx
user:jane:rwx
group::r-x
group:djungle:rwx
mask::rwx
other::---

A Directory with a Default ACL

Directories can have a default ACL, which is a special kind of ACL defining the access permissions
that objects under the directory inherit when they are created. A default ACL affects subdirectories as
well as files.

Effects of a Default ACL

There are two different ways in which the permissions of a directory's default ACL are passed to the
files and subdirectories in it:

 A subdirectory inherits the default ACL of the parent directory both as its own default ACL
and as an access ACL.

 A file inherits the default ACL as its own access ACL.

 All system calls that create file system objects use a mode parameter that defines the access
permissions for the newly created file system object.
 If the parent directory does not have a default ACL, the permission bits as defined by the
umask are subtracted from the permissions as passed by the mode parameter, with the
result being assigned to the new object.
 If a default ACL exists for the parent directory, the permission bits assigned to the new
object correspond to the overlapping portion of the permissions of the mode parameter
and those that are defined in the default ACL and assigned to the object. The umask is
disregarded in this case.

Application of Default ACLs

The following three examples show the main operations for directories and default ACLs:
 Creating a default ACL for an existing directory
 Creating a subdirectory in a directory with default ACL
 Creating a file in a directory with default ACL

1.Add a default ACL to the existing directory mydir with:

setfacl -d -m group:djungle:r-x mydir

The option -d of the setfacl command prompts setfacl to perform the following modifications
(option -m) in the default ACL.

Take a closer look at the result of this command:

getfacl mydir

# file: mydir
# owner: tux
# group: project3
user::rwx
user:jane:rwx
group::r-x
group:djungle:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:djungle:r-x
default:mask::r-x
default:other::---

getfacl returns both the access ACL and the default ACL. The default ACL is formed by all lines that
start with default. Although you merely executed the setfacl command with an entry for the djungle
group for the default ACL, setfacl automatically copied all other entries from the access ACL to create a
valid default ACL. Default ACLs do not have an immediate effect on access permissions. They only come
into play when file system objects are created. These new objects inherit permissions only from the
default ACL of their parent directory.

2. In the next example, use mkdir to create a subdirectory in mydir, which inherits the default ACL.

mkdir mydir/mysubdir

getfacl mydir/mysubdir

# file: mydir/mysubdir
# owner: tux
# group: project3
user::rwx
group::r-x
group:djungle:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:djungle:r-x
default:mask::r-x
default:other::---

As expected, the newly-created subdirectory mysubdir has the permissions from the default ACL
of the parent directory. The access ACL of mysubdir is an exact reflection of the default ACL of
mydir, as is the default ACL that this directory will hand down to its subordinate objects.

3. Use touch to create a file in the mydir directory:

touch mydir/myfile

ls -l mydir/myfile

-rw-r-----+ ... tux project3 ... mydir/myfile

getfacl mydir/myfile

# file: mydir/myfile
# owner: tux
# group: project3
user::rw-
group::r-x # effective:r--
group:djungle:r-x # effective:r--
mask::r--
other::---

touch passes mode with the value 0666, which means that new files are created with read and
write permissions for all user classes, provided no other restrictions exist in umask or in the default ACL
(see section “Effects of a Default ACL”).
 In effect, this means that all access permissions not contained in the mode value are removed from
the respective ACL entries. Although no permissions were removed from the ACL entry of the group
class, the mask entry was modified to mask permissions not set via mode.

This approach ensures the smooth interaction of applications, such as compilers, with ACLs. You can
create files with restricted access permissions and subsequently mark them as executable. The mask
mechanism guarantees that the right users and groups can execute them as desired.

The ACL Check Algorithm

A check algorithm is applied before any process or application is granted access to an ACL-protected
file system object. As a basic rule, the ACL entries are examined in the following sequence: owner,
named user, owning group or named group, and other. The access is handled in accordance with the
entry that best suits the process. Permissions do not accumulate.

Things are more complicated if a process belongs to more than one group and would potentially suit
several group entries. An entry is randomly selected from the suitable entries with the required
permissions. It is irrelevant which of the entries triggers the final result “access granted”. Likewise, if
none of the suitable group entries contains the correct permissions, a randomly selected entry triggers
the final result “access denied”.

A process requests access to a file system object. Two steps are performed. Step one selects the ACL
entry that most closely matches the requesting process. The ACL entries are looked at in the following
order: owner, named users, (owning or named) groups, others. Only a single entry determines access.
Step two checks if the matching entry contains sufficient permissions.

A process can be a member in more than one group, so more than one group entry can match. If any
of these matching group entries contain the requested permissions, one that contains the requested
permissions is picked (the result is the same no matter which entry is picked). If none of the matching
group entries contains the requested permissions, access will be denied no matter which entry is picked.

The access check algorithm can be described in pseudo-code as follows.

If
the user ID of the process is the owner, the owner entry determines access
else if
the user ID of the process matches the qualifier in one of the named user entries, this entry
determines access
else if
one of the group IDs of the process matches the owning group and the owning group entry contains
the requested permissions, this entry determines access
else if
one of the group IDs of the process matches the qualifier of one of the named group entries and this
entry contains the requested permissions, this entry determines access
else if
 one of the group IDs of the process matches the owning group or any of the named group entries,
but neither the owning group entry nor any of the matching named group entries contains the
requested permissions, this determines that access is denied
else
the other entry determines access.
If
the matching entry resulting from this selection is the owner or other entry and it contains the
requested permissions, access is granted
else if
the matching entry is a named user, owning group, or named group entry and this entry contains
the requested permissions and the mask entry also contains the requested permissions (or there is
no mask entry), access is granted
else
access is denied.

ACL Support in Applications

As described in the preceding sections, ACLs can be used to implement very complex permission
scenarios that meet the requirements of modern applications. The traditional permission concept and
ACLs can be combined in a smart manner. However, some important applications still lack ACL support.
Except for the star archiver, there are currently no backup applications that guarantee the full
preservation of ACLs.

The basic file commands (cp, mv, ls, and so on) do support ACLs, but many editors and file managers
(such as Konqueror) do not. When copying files with Konqueror, for instance, the ACLs of these files are
lost. When modifying files with an editor, the ACLs of files are sometimes preserved, sometimes not,
depending on the backup mode of the editor used.
 If the editor writes the changes to the original file, the access ACL will be preserved.
 If the editor saves the updated contents to a new file that is subsequently renamed to the
old file name, the ACLs may be lost, unless the editor supports ACLs.
The more applications support ACLs, the more it will be possible to exploit the great potential of this
feature.

References

https://www-uxsup.csx.cam.ac.uk/pub/doc/suse/suse9.2/suselinux-adminguide_en/ch28s04.html
https://www.linuxtopia.org/online_books/suse_linux_guides/SLES10/suse_enterprise_linux_server_
installation_admin/cha_acls.html
http://www.cs.unibo.it/~sacerdot/doc/papers/AccessControlListInLinux.pdf
https://www.thegeekdiary.com/unix-linux-access-control-lists-acls-basics/