Annotated Mini Tutorial for Access Control Lists (ACLs)

Solaris Advanced System Administrator's Guide, Second Edition
(Imprint: Macmillan Technical Publishing)
(Publisher: Macmillan Computer Publishing)
Author: Janice Winsor
ISBN: 1578700396

Access Control Lists (ACLs, pronounced “ackkls”) can provide greater control over file permissions when traditional UNIX file permissions are not enough. UNIX file protection provides read, write, and execute permissions for three user classes: owner, group, and other. An ACL provides better file security by enabling you to define file permissions for the owner, owner's group, others, specific users, and groups. It also enables you to define default permissions for each of these categories.

For example, you might have two groups that need permission to access a file, one to read it and one to write to it. Alternatively, you might have a file that you wanted everyone in a group to be able to read, so you would give group read permissions on that file. Suppose that you want only two people in the group to be able to write to that file. With standard UNIX permissions, you cannot give write permission to only two members of a group. You can, however, set up an ACL for that file to grant only two people in the group write permissions on that file.

ACLs are extensions to standard UNIX file permissions. The ACL information is stored and associated with each file individually.

ACL Commands

You define an ACL for a file or directory by using the ACL commands and options listed in Table 18-8.

Each ACL entry consists of the following fields, which are separated by colons:

<entry-type>:[<UID>] | [<GID>]:<perms>

Table 18-9 explains each of the elements of the syntax for ACL commands.

---

NOTE:  ACLs are supported in UFS file systems only. If you restore or copy files with ACL entries in the /tmp directory, which is usually mounted as a TMPFS file system, the ACL entries are lost. If you need to temporarily store UFS files containing ACLs, use the /var/tmp directory instead.

---

ACL Permissions for Files

You can set the following permissions for UFS files:

•  u[ser]::<perm> Sets the permissions for the owner of the file.

•  g[roup]::<perm> Sets the permissions for the owner's group.

•  o[ther]::<perm> Sets the permissions for users other than the owner or members of the owner's group.

•  m[ask]::<perm> Sets the ACL mask. The mask entry indicates the maximum permissions allowed for users other than the owner and for groups. Using the mask is a quick way to change permissions on all of the users and groups. For example, the mask:r-- and mask:4 entry indicates that users and groups cannot have more than read permissions, even though they may have write/execute permissions.

•  u[ser]:<UID> | <username>:<perm> Sets the permissions for a specific user.

•  g[roup]:<GID> | <groupname>:<perm> Sets the permissions for a specific group.

ACL Permissions for Directories

You can set default ACL entries on a directory that apply to files subsequently created within the directories. Files created in a directory that has default ACL entries will have the same ACL entries as the directory.

When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the owner, owner's group, others, and the mask.

•  d[efault]:u[ser]::<perm> Sets the default permissions for the owner of the directory.

•  d[efault]:g[roup]::<perm> Sets the default permissions for the owner's group.

•  d[efault]:o[ther]::<perm> Sets the default permissions for users other than the owner or members of the owner's group.

•  d[efault]:m[ask]::<perm> Sets the default ACL mask.

•  d[efault]:u[ser]:<UID>:<perm> Sets the default permissions for a specific user.

•  d[efault]:g[roup]:<GID>:<perm> Sets the default permissions for a specific group.

Determining If a File Has an ACL

You can determine if a file has an ACL in one of two ways:

•  By using the ls -l command

•  By using the getfacl command

When you use the ls -l command, any file that has an ACL displays a plus (+) sign to the right of the mode field.

---

NOTE:  If you define an ACL for a file and do not specify any additional users or groups, the plus sign is not displayed to the right of the mode field even though the file has a basic ACL. The plus sign is displayed only if additional users or groups are included in the ACL.

---

In the following example, the file foo has an ACL and at least one entry in the list:

castle% ls -l foo
-rwxrw—+  1 winsor  staff      0 Oct 3 14:22 foo
castle

When you use the getfacl <filename> command with no options, the ACL information for the file is displayed in the following format:

# file: filename
# owner: uid
# group: gid
user::perm
user:uid:perm
group::perm
group:gid:perm
mask:perm
other:perm
default:user::perm
default:user:uid:perm
default:group::perm
default:group:gid:perm

The ACL for the file foo in the following example gives the owner of the file rwx permissions and user ray read-only permissions:

castle% getfacl foo

# file: foo
# owner: winsor
# group: staff
user::rwx
user:ray:r--         #effective:r--
group::rw-           #effective:rw-
mask:rw-
other:---
castle%

---

NOTE:  You can use the getfacl command to display permissions on any UFS file or directory in the same format. The file does not need to have an ACL.

---

For comparison, the following example shows the output of the ls -l and getfacl commands for the file bar, which does not have an ACL.

castle% ls -l bar
-rwxrw—       1 winsor  staff     0 Oct 3 14:22 bar
castle% getfacl bar

# file: bar
# owner: winsor
# group: staff
user::rwx
group::rw-           #effective:rw-
mask:rw-
other:—
castle%

Setting ACL File Permissions

Use the setfacl command to set ACL permissions on a file. You can set the permissions for a file or a group of files from a command line or by listing the permissions in a file and using the file as an argument to the setfacl command. You can specify the permissions with the following syntax:

u[ser]::<perm>
u[ser]:uid:<perm>
g[roup]::<perm>
g[roup]:gid:<perm>
m[ask]:<perm>
o[ther]:<perm>
d[efault]:u[ser]::<perm>
d[efault]:u[ser]:uid:<perm>
d[efault]:g[roup]::<perm>
d[efault]:g[roup]:gid:<perm>
d[efault]:m[ask]:<perm>
d[efault]:o[ther]:<perm>

NOTE:  You can use either octal or symbolic values to set permissions.

On a command line, use a comma to separate each permission statement. In an ACL file, put each statement on a separate line. The statements do not need to be in any particular order

Setting Permissions for a File from a Command Line

To set ACL permissions from a command line, you must specify at least the basic set of user, group, other, and mask permissions. Type the following command to set ACL permissions: setfacl -s u::<perm>,g::<perm>,o:<perm>, m:<perm>, [u:<UID>:<perm>], [g:<GID>:<perm>

You can set users by using either their username or their UID number. Note that before you can use the username argument, the user account must already exist in the Passwd database or in the local /etc/passwd file. You can assign permissions to any UID by number, regardless of whether a user account exists.

In the same way, you can set group names by using either the group name or the GID number.

The following example assigns all of the permissions to the user, restricts group permissions to read-only, and denies permissions to other. The default mask sets read-write permissions, and user ray is assigned read-write permissions to the file foo.

First, take a look at the current permissions for the file:

castle% ls -l foo
-rw-rw-rw-    1 winsor       staff      0 Oct 3 14:22 foo

Then set permissions for user, group, owner, and the mask and add one user to the ACL:

castle% setfacl -s u::rwx,g::r—,o:—,mask:rw-,u:ray:rw- foo

Using octal values, as shown in the following example, gives you the same result:

castle% setfacl -s u::7,g::4,o:0,mask:6,u:ray:6 foo

Next, verify that the permissions have been set and that the file has an ACL:

castle% ls -l foo
-rwxrw—    +  1 winsor   staff      0 Oct  3 14:22 foo

As you can see, the permissions for the file are changed and the plus sign after the permission field shows that the file has an ACL. Last, use the getfacl command to verify that everything has been set correctly:

castle% getfacl foo

# file: foo
# owner: winsor
# group: staff
user::rwx
user:ray:rw-         #effective:rw-
group::rw-           #effective:rw-
mask:rw-
other:—
castle%

The getfacl command always displays ACL permissions symbolically, regardless of how you specify the values from the command line.

Using an ACL Configuration File to Set Permissions

You can create an ACL configuration file that contains a list of the permissions you want to set and then use that filename as an argument to the setfacl -s command.

---

NOTE:  You can use a configuration file only with the -s option to the setfacl command.

---

Use the following steps to set up the ACL configuration file:

1.  Use any editor to create a file.

2.  Edit the file to include the permissions you want to set, putting each statement on a separate line. Be sure to include permissions for user, group, other, and mask as a minimum set.

3.  Save the file by using any filename you choose.

4.  Type setfacl -f <acl_filename> <filename1> [<filename2>] [<filename3>] and press Return.

5.  Type getfacl <filename1> [<filename2>] [<filename3>] and press Return to verify that the permissions are set correctly.

---

NOTE:  If you make typographical errors in the configuration file, the command might return a prompt without displaying any error messages. If you make syntax errors, the setfacl command might display an error message. Be sure to use the getfacl command to check that the permissions are set properly.

---

In the following example, the owner has rwx permissions, group has rw-, other has —, and the mask is rw-. Three users with different permissions are also granted access to the file. The acl_file (named anything) contains the following access list:

u::rwx
g::rw-
o:—
m:rw-
u:ray:rwx
u:des:rw-
u:rob:r—

Once you have set up the ACL for the file named anything, you can use the setfacl -f option to assign those same permissions to one more file. In the following example, the file named anything is used as the argument to the -f option to change ACLs for the files foo and bar so that they match the file anything:

castle% setfacl -f anything foo bar
castle% getfacl foo bar

# file: foo
# owner: winsor
# group: staff
user::rwx
user:ray:rwx         #effective:rwx
user:des:rw-         #effective:rw-
user:rob:r—         #effective:r—
group::rw-           #effective:rw-
mask:rw-
other:—

# file: bar
# owner: winsor
# group: staff
user::rwx
user:ray:rwx         #effective:rwx
user:des:rw-         #effective:rw-
user:rob:r—         #effective:r—
group::rw-           #effective:rw-
mask:rw-
other:—
castle%

Adding and Modifying ACL Permissions

You can add and modify ACL permissions for a file that already has an ACL or for any existing UFS file or directory by using the setfacl -m command. Arguments to the setfacl -m command use the same syntax and structure as arguments to the setfacl -s command.

Because each file already has a default owner, group, other, and mask setting, you can use the setfacl -m command on any UFS file without first using the setfacl -s command to specify an owner, group, other, or mask setting. If the file already has the permissions you want to use, you can simply use the setfacl -m command to modify (and create) the ACL for any file or directory.

When you use the -m option, if an entry already exists for a specified UID or GID, the permissions you specify replace the current permissions. If an entry does not exist, it is created.

Type the following syntax to add and modify permissions for a file or files and press Return:

setfacl -m <acl_entry_list><filename1> [<filename2>] [<filename3>]

In the following example, permissions for user ray are modified from rwx to rw- for the file foo.

castle% setfacl -m u:ray:rw- foo
castle% getfacl foo

# file: foo
# owner: winsor
# group: staff
user::rw-
user:ray:rw-         #effective:rw-
group::rw-           #effective:rw-
mask:rw-
other:rw-
castle%

Deleting an ACL Entry

Use the setfacl -d command to delete an ACL entry. To delete the entry, you can specify the entry type and the UID or GID. You do not need to include the permissions as part of the argument to the -d option.

Type the following syntax to delete an ACL entry and then press Return:

setfacl -d<entry_type>:<UID> | <GID> <filename1> [<filename2>] [<filename3>]

In the following example, user ray is deleted from the ACL of the file foo.

castle% setfacl -d u:ray foo
castle% getfacl
usage: getfacl [-ad] file ...
castle% getfacl foo

# file: foo
# owner: winsor
# group: staff
user::rw-
group::rw-           #effective:rw-
mask:rw-
other:rw-
castle%

Copying ACL File Permissions

You can copy ACL file permissions from one file to another without specifying them on the command line by piping the output of getfacl <filename> to another file by typing the following syntax and pressing Return:

getfacl <filename1> | setfacl -f - <filename2>

In the following example, the ACL for file foo is used as the template for the ACL for file bar.

First, verify that the files have different ACL permissions:

castle% getfacl foo bar

# file: foo
# owner: winsor
# group: staff
user::rw-
user:ray:rwx         #effective:rw-
group::rw-          #effective:rw-
mask:rw-
other:rw-

# file: bar
# owner: winsor
# group: staff
user::rw-
group::rw-           #effective:rw-
mask:rw-
other:rw-

Then list the ACL using the getfacl command and pipe the output to the setfacl -f command. The dash (-) tells the setfacl command to use the output from the file specified for the getfacl command as input to the second file.

castle% getfacl foo | setfacl -f - bar

Finally, use the getfacl command to verify that both files now have the same ACL permissions:

castle% getfacl foo bar

# file: foo
# owner: winsor
# group: staff
user::rw-
user:ray:rwx         #effective:rw-
group::rw-          #effective:rw-
mask:rw-
other:rw-

# file: bar
# owner: winsor
# group: staff
user::rw-
user:ray:rwx         #effective:rw-
group::rw-          #effective:rw-
mask:rw-
other:rw-
castle%

Network Security

Networks create an interesting access and security paradox. Users on a network almost always push for freer access to information and files. System administrators almost always push for more restrictive access to information and files so that they can more effectively monitor use and secure access to sensitive information.

Network security is usually based on limiting or blocking operations from remote systems.

Network security comprises three aspects: firewall, authentication, and authorization, as illustrated in Figure 18-1.

Figure 18-1  Security Restrictions for remote operations.

Firewall Systems

The purpose of creating a firewall network security system is to ensure that all of the communication between a local network and an external network conforms to your local network security policy. A network security policy can be permissive or restrictive. A permissive policy might allow access to all services unless specifically denied. A restrictive policy might deny access to all services unless specifically allowed.

You can set up a firewall system to help protect the resources in your network from outside access. A firewall system acts as a barrier between your internal network and outside networks.

The firewall has two functions:

•  It acts as a gateway that passes data between the networks.

•  It acts as a barrier that blocks the free passage of data to and from the network.

---

CAUTION! A firewall prevents unauthorized users from accessing hosts on your network. Maintain strict and rigidly enforced security on the firewall. However, an intruder who can break into your firewall system may be able to gain access to all of the other hosts on the internal network.

---

A firewall system should not have any trusted hosts. A trusted host is one from which a user can log in without being required to type in a password. The firewall system should not share any of its file systems or mount any file systems from other servers.

You can use ASET to make a system into a firewall and to enforce high security on a firewall system. For more information on ASET, refer to Chapter 20.

Two good reference books on firewalls are Firewalls & Internet Security: Repelling the Wily Hacker by Steven Cheswick and William Bellovin and Building Internet Firewalls by D. Brent Chapman and Elizabeth D. Zwicky. (See bibliography at the end of this book.)

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019