Child pages
  • Using Unix Acess Control Lists (ACLs)
Skip to end of metadata
Go to start of metadata

This document contains information about using Access Control Lists to control access to files and directories on the SoIC Linux systems. You may also want to see the Unix File Permissions KB entry to get further information about basic file and directory permissions under Unix/Linux.

Index

  1. ACL Introduction
  2. Before You Begin
  3. Gotchas
  4. Basic Commands and Operations
  5. ACLs on Directories
  6. A Cookbook Example
  7. Emacs and Disk Quota Notes
  8. Other Sources of Information

This document contains information about using Access Control Lists to control access to files and directories on the SoIC Linux systems. You may also want to see the Unix File Permissions KB entry to get further information about basic file and directory permissions under Unix/Linux.

ACL Introduction

Under Linux you can use what are called Access Control Lists, or ACLs. The ACL functionality gives a user the ability to, among other things, grant file permissions on a user-by-user basis. So, for example, you can create a file that is readable by joeuser and janeuser but only writable by janeuser. ACLs provide a much higher degree of control over permissions than standard Unix groups. In addition, they are completely under the control of the owner of the file. You don't need the system administrator to create and maintain groups for you.

Before You Begin

ACLs can be tricky and in many cases all you want to do is something very simple like open up a directory and everything in it for read or read/write access to another user. If this is all you want to do, then we have a little helper script named acl_open that you can use to accomplish this. The usage of this script is as follows:

   USAGE: acl_open [-r] directory user

     -r   read-only (default is read/write)

So, if all you want to do is set up a directory (call it "GroupProject") in your home directory that is readable and writable by the user janedoe, then just run:

   mkdir GroupProject
   acl_open GroupProject janedoe

If you only want to give read access instead of read/write, just add the -r flag:

   acl_open -r GroupProject janedoe

Now, of course, things are never simple so please read the next section (Gotchas) for things that are likely to trip you up.

Gotchas

There are any number of ways that ACLs can work unexpectedly, but here are the most common pitfalls:

  • NFSv4 vs NFSv3 - We are using different version of the Network File System (NFS) on servers (like burrow, sharks, tank, hulk, and moose) and normal workstations. The servers are running NFSv3 and there should be no problems at all with ACLs on these systems. However, on the client workstations (basically any system you can log into on the console) they are running NFSv4 and you may find that default ACLs don't always work as you would expect.  Therefore, we recommend that you do anything you need to do to create files in directories with default ACLs on the servers. Also, if you used acl_open to set your ACLs, you can always re-run this command after you create your files to fix up the ACLs.
  • Copying Files - Even though acl_open sets the default ACLs so that files created in that directory should be readable by janedoe, it is still possible for you to create files in ways that makes them not readable. For example, if you create a new file using an editor (ie. pico, vi, emacs) then the default ACLs should be inherited correctly. However, if you copy files using cp you may find that cp tried to preserve permissions from the original file and that the ACLs were not set properly. If you used acl_open to set your acls, you can always re-run this command after you copy your files.
  • Incorrect masks - In addition to the permission set via ACLs there is also a "mask". This mask value is used to calculate an effective that is in effect. So, for example, if you give user joedoe read/write (rw-) permissions on a file but the mask is set to r-- then the effective permissions in effect will be r-- (read-only). You can see this with getfacl like this:
    	% getfacl some_file
    	...
    	user:joedoe:rw-               #effective:r--
    	...
    	mask::r-x
    
    You can always reset the mask with something like:
    	setfacl -m mask::rwx some_file

    Or, if you used acl_open to set your acls, you can always re-run this command to correct any mask problems.

Basic Commands and Operations

The two main commands you will use to manipulate ACLs are setfacl and getfacl. For example, if I have a file named hello.c, I can grant read-only access to user shei with:

setfacl -m user:shei:r-- hello.c

and read-write access to user schisham with:

setfacl -m user:schisham:rw- hello.c

After setting the ACL on the file, note that ls shows a + after the normal permission list:

	% ls -l hello.c
	-rw-rw----+   1 robh     staff           0 Sep  3 10:07 hello.c

The + signifies that there is an ACL set for the file. You can then use getfacl to display the ACL for the file:

	% getfacl hello.c

	user::rw-
	user:shei:r--           #effective:r--
	user:schisham:rw-               #effective:rw-
	group::rw-              #effective:rw-
	mask:rw-
	other:---

The ACL shows that user shei has read access and user schisham has read/write access. Once you have an ACL set on one file, you can duplicate this ACL for other files by creating an ACL file and using this to set the ACL of other files:

	% getfacl hello.c> ACLfile
	% setfacl -M ACLfile goodbye.c

You can do the same thing without actually creating the ACLfile using:

getfacl hello.c | setfacl -M - goodbye.c

ACLs on Directories

You can also set ACLs on directories as well as on files. ACLs on directories introduce a new concept called the default ACL for the directory. This default ACL is used to set the ACL for all files that are created within the directory. To do this, you can specify the default ACL with something like the following:

setfacl -m default:user::rw-,default:group::---,default:mask:rwx,default:other:--- SomeDirectory

which only gives the owner read/write/execute (rwx) permission on the files created in the directory. You can then give user shei read and execute permission on the directory:

setfacl -m user:shei:r-x SomeDirectory

and read access to all files created in the directory:

setfacl -m default:user:shei:r-- SomeDirectory

You probably also want to give yourself read access for files created in the directory so that you can access files other users create.

setfacl -m default:user:robh:r-- SomeDirectory

A Cookbook Example

This section describes the procedure for using ACLs to share files in a group project directory. The example assumes that multiple people will be editing a common source file and building an executable from this file.

First, make the shared directory

% mkdir GroupProject

Then, give user juser write permission on the directory

% setfacl -m user:juser:rwx GroupProject

Give user juser and yourself read/write permission to files created in the directory

% setfacl -m default:user:juser:rwx GroupProject
% setfacl -m default:user:robh:rwx GroupProject

Note that you would replace "robh" with your username. Then, cd to the directory and create a file we need to share

% cd GroupProject
% vi hello.c

We see that juser has read and write access to this file:

	% getfacl hello.c

	user::rw-
	user:juser:rwx         #effective:rw-
	group::---              #effective:---
	mask:rw-
	other:---

We then create an executable named hello from hello.c:

	% make hello
	cc -o hello hello.c
	%

We then check the ACL for the hello executable:

	% getfacl hello

	user::rwx
	user:juser:rwx         #effective:rwx
	group::---              #effective:---
	mask:rwx
	other:---

You see that, as with the other file we created, user juser has write permission. So, juser could then come and edit the hello.c file and rebuild the hello executable.

Emacs and Disk Quota Notes

Also note that there are implications related to disk quotas. For example, if user1 grants write access for a directory to user2, then any files that user2 creates in that directory fall within the quota contraints for user2 on that partition. If user1 and user2 are are different disk partitions, then user2 will have a zero quota on that partition and will not be able to create files. There are two workarounds for this problem. First, you can request that home directories be moved to a single partition. Second, if user1 creates a file then user2 can edit the file as long as the ownership doesn't change. Some editors, such as emacs, like to rewrite files thereby changing the ownership which will fail. In emacs, you can add the following to your .emacs file to prevent emacs from rewriting files:

(setq backup-by-copying t)

Other Sources of Information

Probably the best source of additional information is the man pages for setfacl and getfacl.  At any command prompt, just run "man getfacl" or "man setfacl".