Using FreeBSD's ACLsby Dru Lavigne
Five years ago (gee, has it really been that long?), I wrote a series of articles on understanding Unix permissions. Since then, FreeBSD has implemented something known as ACLs (Access Control Lists).
ACLs came to BSD as part of the TrustedBSD project. As the name suggests, they give a user finer access control over permissions.
Why Would I Want to Use ACLs?
While ACLs don't change the standard Unix permissions of (r)ead, (w)rite, and e(x)ecute, they do give you better control over whom those permissions affect. Here's a simple example--as a regular user, create a test file in the system's temporary directory:
% touch /tmp/test % ls -l /tmp/test -rw-r--r-- 1 dru dru 0 Jul 26 15:43 /tmp/test
I've chosen this directory as all users have write access here and it is a good place to test out permissions. However, don't keep important files here, because they are likely to disappear, depending on how the system administrator has configured the cleaning of this directory!
In this example, the creator of the file,
rw access; anyone in the group
access; and everyone else has
r access. Note that when you create
a user in FreeBSD, you also get a group of the same name with that user as the
Now suppose that I need to give the users
toby write access to this file. As the permissions stand now, they
might be able to open the file in an editor, but they won't be able to save any
changes, as they are neither the user
dru nor a member of the
dru group. They fall into
other, which has read permission only.
Before ACLs, the typical solution to this dilemma was to modify group
memberships. I could, for example, ask the system administrator to add
toby to the
dru group. I could
chmod to add write permission to the
group for this file. This is slightly better than giving write permission to
other, as that would allow anyone on the system to write to that file.
Alternatively, the system administrator could carefully plan out which users
need access to which files and then create groups and assign users to those
groups. Then, assuming a user belonged to the required group, she could use the
chgrp command on the files she created in order to change group
Neither system is perfect, however. For one, it requires bugging the system
administrator, which is inconvenient when all you want to do is share your own
files. Further, consider another scenario. Suppose that
toby have all been made members of the newly
workgroup group. All three group members can write to any
files with write permission for
workgroup, regardless of which one originally
created the file. But what if
rob to write
to one of these files but not
This is starting to sound pretty complicated, isn't it? Fortunately, this is
the reason behind ACLs. Without having to ask the administrator to make a bunch
of groups or having to use
dru can easily pick
and choose through her files and decide which files
rob gets write
access to; she can also give
toby write access to a different set
This article shows how you, as the system administrator, can prepare a FreeBSD system for ACLs. I'll then demonstrate a GUI utility, which will allow your users to easily control the ACLs on their own files. Finally, I'll show you how to back up files containing ACLs.
Preparing the System
If you're using FreeBSD 5.1 or later, ACL support is already built into your kernel and UFS2 filesystem.
(With earlier versions of FreeBSD, see Daniel Harris's article on ACLs for instructions for compiling ACL support into FreeBSD.)
You simply need to decide on which filesystem(s) you wish to use ACLs:
# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 253678 35764 197620 15% / devfs 1 1 0 100% /dev /dev/ad0s1e 253678 22 233362 0% /tmp /dev/ad0s1f 8077406 3045460 4385754 41% /usr /dev/ad0s1d 253678 21048 212336 9% /var
On my system, I wanted to enable ACLs only for users, so I configured only the /usr filesystem.
The FreeBSD handbook explains the advantages of using
tunefs command to enable ACLs. The disadvantage is
that it requires bringing the system down to single-user mode and unmounting
the filesystem. Choose a time that will least impact users; once you're sure
no one is connected to the system, use the following:
# shutdown now Enter full pathname of shell or RETURN for /bin/sh: # /sbin/umount /usr # /sbin/tunefs -a enable /dev/ad0s1f tunefs: ACLs set # /sbin/mount /usr
Use your output from
df to know the name of the device on which
you wish to enable ACLs (
Then, to see if it worked:
# /sbin/mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, local, soft-updates, acls) /dev/ad0s1d on /var (ufs, local, soft-updates)
And to bring the system back to multiuser mode:
That's it. ACLs are now enabled on /usr.