Among the challenges of administering Linux in the modern business environment is the expectation that we can and should manage who has access to what information. Once upon a time, the only folks who needed access to Linux filesystems could be categorized in a general way: through Linux filesystem permissions.
Reviewing the basics
The Linux filesystem gives us three types of permissions. Here is a simplified review:
- User (or user owner)
- Group (or owner group)
- Other (everyone else)
With these permissions, we can grant three (actually five, but we’ll get to that in a minute) types of access:
These levels of access are often adequate in many cases. Say that you have a directory where files from the accounting department live. You might set these permissions to:
drwxrwxr-x 2 accounting accounting 12 Jan 8 15:13
The accounting service user (the user owner) can read and write to the directory, and members of the
accounting group (or owner group) can read and write. Others (users not in the accounting department) can, however, see and execute what’s in there, which some might think is a bad idea.
[ Also popular: Linux sysadmin basics: User account management ]
So, we might change the permissions to this:
drwxrwx--- 2 accounting accounting 12 Jan 8 15:13 .
Note: You can also use special permissions to control settings like who actually owns new files created in that directory, as well as the sticky bit which controls whether members of the group can delete each other's files. However, that's outside the scope of this discussion.
Viewing the current ACL
What if you have an accounting intern (Kenny) who needs to be able to read certain files (or even just the files owned by Fred, his manager)? Or maybe people in the sales department also need access to the
accounting owner’s files to create invoices for Fred’s team in order to bill customers, but you don’t want the sales team to see the other reports that Fred's team generates. This situation can be tricky because, with regular permissions, each file and directory can have only one user and group owner at a time. This type of situation is what Linux Access Control Lists (ACLs) were intended to resolve.
ACLs allow us to apply a more specific set of permissions to a file or directory without (necessarily) changing the base ownership and permissions. They let us "tack on" access for other users or groups.
We can view the current ACL using the
[root]# getfacl /accounting getfacl: Removing leading '/' from absolute path names # file: accounting # owner: accounting # group: accounting user::rwx group::rwx other::---
We can see that right now, there are no ACLs on this directory because the only permissions listed are for the user, group, and other. In this case, that's to be expected, because I just created this directory in the lab and haven't done anything other than assigning ownership. So, let's start by adding a default ACL:
Setting an ACL
The syntax for setting an ACL looks like this:
setfacl [option] [action/specification] file
The 'action' would be
-m (modify) or
-x (remove), and the specification would be the user or group followed by the permissions we want to set. In this case, we would use the option
-d (defaults). So, to set the default ACL for this directory, we would execute:
[root]# setfacl -d -m accounting:rwx /accounting
After which we can now see the default ACL info for that directory:
[root]# getfacl /accounting [root]# getfacl: Removing leading '/' from absolute path names # file: accounting # owner: accounting # group: accounting user::rwx group::rwx other::--- default:user::rwx default:user:accounting:rwx default:group::rwx default:mask::rwx default:other::---
What if Fred creates a file in that directory?
[fred]$ touch test [fred]$ ls -la drwxrwx---+ 2 accounting accounting 18 Jan 8 17:51 . dr-xr-xr-x. 18 root root 262 Jan 8 15:13 .. -rw-rw----+ 1 fred accounting 0 Jan 8 17:51 test [fred]$ getfacl test # file: test # owner: fred # group: accounting user::rw- user:accounting:rwx #effective:rw- group::rwx #effective:rw-
What happens if Kenny tries to create a file? You may be able to guess that because
kenny is not in the
accounting group, he won’t have permission. But we want Kenny to have a good experience working with us, so we need to give him the ability to see what files are in the
accounting directory, and we want him to be able to create new files:
[root@lab1 accounting]setfacl -m kenny:rwx /accounting [root]getfacl ./ # file: . # owner: accounting # group: accounting user::rwx user:kenny:rwx
So far so good. But what if we don’t want this user to create files in the
accounting directory? Instead, we only want to let him read the files there, and he can create new files in his own folder.
[ Related article: Linux sysadmin basics: User account management with UIDs and GIDs ]
We can set Kenny’s access on the
accounting folder like this:
[root@lab1 accounting]# setfacl -m kenny:r-x /accounting [root]# getfacl ./ # file: . # owner: accounting # group: accounting user::rwx User:kenny:r-x
Now we make Kenny his own folder, give him ownership, and then make the
accounting group the group owner so that other people in the
accounting group can see what’s in there:
[root@lab1 accounting]# mkdir ./kenny [root]# chown kenny:accounting ./kenny [root]# getfacl ./kenny # file: kenny # owner: kenny # group: accounting user::rwx user:accounting:rwx group::rwx
You've created a folder within the
accounting group that's owned by the user
kenny. He now is able to see the accounting folder, but only create files in his own folder:
[root@lab1 accounting]# su kenny [kenny]$ touch test touch: cannot touch ‘test’: Permission denied [kenny]$ cd ./kenny [kenny]$ touch test [kenny]$ ls test
Note that because the folder is owned by the
accounting group, anyone in that group can put files there. Because we’re dealing with an intern, this factor is probably fine. However, what if we give Kenny a promotion to chief auditor and want to keep his work a secret from Fred?
[root]# setfacl -m fred:- ./kenny [root]# getfacl ./kenny # file: kenny # owner: kenny # group: accounting user::rwx user:accounting:--- user:fred:---
What if we didn’t want anyone to see what Kenny is working on?
[root]# setfacl -m g:accounting:- ./kenny
Note: When we want to set a group ACL, we need to specify this by putting
g: in front of the group’s name. For users, just change the
g to a
setfacl will assume we are talking about a user if you don’t put anything in that spot.
We still have to remove the base permissions for the group owner so that the rest of the accounting team can’t snoop into Kenny’s reports:
[root]# chmod g-rwx ./kenny [root]# ls -al total 0 drwxrwx-wx+ 3 accounting accounting 44 Jan 9 16:38 . dr-xr-xr-x. 18 root root 262 Jan 8 15:13 .. drwx------+ 2 kenny accounting 18 Jan 9 17:07 kenny -rw-rw----+ 1 root root 0 Jan 9 16:33 test -rw-rw----+ 1 kenny accounting 0 Jan 9 16:27 test2 [root]# getfacl ./kenny # file: kenny # owner: kenny # group: accounting user::rwx user:accounting:--- user:fred:--- group::rwx #effective:--- [root]# su jan [jan]$ touch ./kenny/test touch: cannot touch ‘./kenny/test’: Permission denied
Now we can manage who else can see or write to Kenny’s folder without changing the ownership. Let’s give the CEO (Lisa, who is not a member of the accounting team, and won’t have access to the rest of the folder) access to Kenny’s stuff:
[root@lab1 accounting]# useradd lisa [root]# setfacl -m u:lisa:rwx ./kenny [root]# su lisa [lisa]$ touch ./kenny/lisa [lisa]$ ls ./kenny lisa test [lisa]$ touch test touch: cannot touch ‘test’: Permission denied [root]# getfacl ./kenny # file: kenny # owner: kenny # group: accounting user::rwx user:accounting:--- user:fred:--- user:lisa:rwx group::rwx group:accounting:---
Note again that the group owner permissions remain wide open, but the accounting group (which is still the owner), no longer has access to that folder. So, who owns it?
drwxrwx---+ 2 kenny accounting 30 Jan 9 17:16 kenny
This part is tricky. It’s useful to know that we can take away the owner’s permissions without changing ownership, but you might want to consider whether this is the result you want.
So these are the basics. ACLs can be confusing, so I encourage you to give the man pages for
getfacl a good read. There are many more interesting and useful things you can do with these tools, but hopefully, you now understand enough to get you started.
[ Want to try out Red Hat Enterprise Linux? Download it now for free. ]