The Real Skinny on ACLs - A Practical Approach with Ubuntu and Samba in Mind

Setting up 18 TB RAID File Server with Ubuntu and ACLs

Published on Jan. 23, 2014 by nick

Tags: acls, ubuntu, networking, samba

After quite some time trying to figure out the best way to handle permissions on an 18 TB file server, hosting 10 or so clients, I realized that ACLs were the way to go. Access control lists give the administrator more granular control over the permissions on the host file system. You might think you can handle it with just the basics, or even with the SGID method (g+s) but even this leaves users creating directories and files that are uneditable by other users. In an open system, your goal as an administrator is to allow your users to share data but not allow guests or outsiders access. In this particular case, I needed all the data to be rw for all users in the Samba list.

What I found when I started doing my research is that there wasn't one good resource that a) answered the basic questions about ACLS but also b) gave several examples for common usage. Sure, you can go to man pages, but I often find that testing and trying is the best way to learn. Often, following a couple tried and true examples illustrates how and why you would want to use any particular set of rules. ACLs are no exception.

In this article, I will describe my problem, and then outline the approach I took to solve it.

Moving from a heterogeneous file sharing system consisting of multiple NASes of different manufacturers, all having diffrerent permissions, owners, groups spread out over a poorly designed network is about the least pleasng way to negotiate your way around 8 TB of data. So when I got the go ahead to build a new file server, needless to say, I was overjoyed.

I've described the file server in previous posts, so I wont go into that here. But suffice it to say that I got to use good components and plan it so it would work for the long haul. You see, that was part of the problem... we kept piling on 2-4 TB NAS after 2-4 TB NAS, to the point where we had multiple devices and an overly complex backup system in palce. This was going away. The file server would replace the NAS devices and then the NAS devices would become the backup storage devices. Two birds, one stone, eh?

Once the machine was built and all the data transfered, I began backing everything up. This entire set of transfers took a long time, as expected, but eventually I was faced with having to make the data available to my users. I had set up a user and group that I would use for data transport, and I added users to that group. I then set up Samba and created Samba user credentials for users in the network who would be accessing the data. I went with the user-level security, because I wanted everyone to use their network and system logins to access the shares.

This actually worked out pretty good, since I also employed the SGID options on all the directories. However, I was still left with the common scenario where a user would create a file and those permissions on that file wouldn't necessarily be writable by users or group members. This article shows explains this predicament very well.

To address this I turned to ACLs. Turns out, with access control lists you can set almost meta-like permissions on directories and files that allow more users and groups to have access to these files. For example, assume you have a directory like so:

user@box:~$ ls -lha /var/www/
total 20K
drwxr-xr-x  5 root   root   4.0K Jan 20 22:04 .
drwxr-xr-x  3 root   root   4.0K Jan 23 12:27 ..
drwxr-xr-x  4 root   web   4.0K Jan 23 20:54 website

If you then issue an ACL command like so, you can do some interesting things:

sudo setfacl -Rm g:daemon:rwx,d:g:daemon:rwx /var/www

Now, even though root owns the directory and the group is web, daemon has rwx on that directory. You can always check the ACL with the getfacl command.

user@box:~$ getfacl /var/www/
getfacl: Removing leading '/' from absolute path names
# file: var/www/
# owner: root
# group: web
user::rwx
group::r-x
group:daemon:rwx
mask::rwx
other::r-x

And if you are running certain distributions of Apache, this is something you might need to do. Of course, in this case you could just as easily just set the owner and group to daemon:daemon, but you get the picture. You might not always want to change the ownership and/or the group permissions on the directories.

In my case, I applied this same idea to the entire set of shares. Now each user can read and write to the directories and files, the group is always the same and because I applied the ACLs recursively, the files created are all set with the correct permissions.

To wrap this article up, I wanted to include a list of common setfacl commands for a quick reference. Im still in the process of compiling the list, so check back soon. Enjoy...