Fun With Access Control Lists In Xsan 1.4

jstaloff's picture

[Ed. Note:]On Friday, September 8, Apple vaguely reported security problems with ACLs if Windows clients are currently or were formerly part of the SAN. See [story:20060909200331395] for more information.

Xsan 1.4 is finally out, and the new version brings with it some improvements a lot of us have been waiting for. Perhaps the biggest news is support for LUNs over 2 terabytes, so you can use the entire capacity of a fully populated Xserve RAID without taking a performance hit. The updated Xsan should also facilitate adding storage to an existing volume and boost performance for volumes that are shared out over network protocols like AFP and SMB. (Update details at Apple's download page)

One less obvious improvement will benefit Xsan’s IT datacenter and media production customers alike, and this is support for filesystem-level access control lists, or ACLs.

What’s All The Commotion About?

We know that from the beginning, Mac OS X’s Unix-style file permissions determine what users can do to a given file or folder. Even for home Macs with just a single user, the dreaded “permission problem” is lurking behind printing errors, failure to save files, and login failures.
On the server side, filesystem permissions have been with us even longer than that. The operators among us who have worked with AppleShare IP, the pre-Mac OS X server platform, know that its permissions model was very similar to the Unix model.

Handy as Unix file permissions are, they’re not as flexible as a model based on ACLs. For an exceptionally in-depth review of how ACLs differ from Unix permissions, I’d refer you to the appropriate section of Ars Technica’s Tiger coverage.

The upshot of it is that ACLs, like the Mac OS X firewall, parses a list of statements as it decides whether to permit a file operation. This lets you do things like assigning write access to multiple individual users without having to define a group, or giving certain parties rights to delete but not read or write a file.


Leave Umask Out Of This

In an Xsan environment, ACLs can also help with an issue once requiring a bit of a hack. In most small environments such as a video post house, all users of the Xsan need to read and write each other’s projects and media. On a file server, we can address that need by defining the share to use inherited permissions. That’s no help with Xsan, though, because the client sees a local volume rather than a network share.

In this situation, we typically use Open Directory to make sure everyone is in the same primary group (called staff, by default), and then we change the umask parameter on each Mac. The Mac’s default umask dictates that a new file will be group-owned by the creator’s primary group, which has read-only access to the file. By changing the umask, we can force the Mac to give read/write access to the group as well as the owner for all new files. When we do this in a new SAN installation, the users are able to save each other’s projects and make new files within folders created by their colleagues. (This process has been documented in detail on Xsanity.)

It becomes a headache, though, when SAN clients are upgraded, replaced, or clean-installed. Setting ACLs is a much more elegant and scalable solution; ACLs were supported with the release of Tiger, but it has taken till now to integrate them into Xsan. Let’s roll up our sleeves and dig in!


Look Before You Leap

Because of their inherent flexibility, it pays to sit down and give some thought to what restrictions you need, who your users are, and what policy implications your future growth might bring. Applying ACLs haphazardly could cause a major headache. Come up with a plan, document it, and think holistically when you make changes to it.

One way to stay organized is to use ACL inheritance. As with AFP, inheritance lets us define ACLs that will be carried through from a folder to any files that are created inside it. Inheritance also means that a user’s rights to a given file might be coming from a number of places, though, so we’re not off the hook with planning and documentation!


Let’s Try It Out

The nuts and bolts of setting up ACL support for an Xsan volume are covered step-by-step in the new Xsan 1.4 Admin Guide. To get started, you’ll need Xsan 1.4 running on Mac OS X 10.4, with your SAN clients logging into Open Directory accounts. We tested this on Mac OS X Server 10.4.7; we’re not aware of specific ACL-related bugs in prior patches, but keep an eye out if you’re below that. Panther Xsan clients will not be able to take advantage of ACLs on the SAN.

Finally, The ACL support in Xsan 1.4 may require a minor update to the LDAP schema on your Open Directory server, if your server was running Mac OS X Server 10.4.5 or earlier when your LDAP database was created. Apple has written a knowledge base article with a nice shell script to help out with that.

First off, the Xsan volume has to be prepared. After the upgrade to 1.4, there is a new checkbox in the volume settings panel. Double click the volume under the Storage section of the SAN Setup.

We’ll use Workgroup Manager to define the ACLs and apply them to your Xsan volume (or a subfolder). Make sure to connect your Workgroup Manager to a Mac that is part of the Open Directory domain and also has the SAN volume mounted on it. The standby metadata controller is a perfect candidate.
Let’s say I want to create a folder so that everyone in the editors group can read and write anything in it. I log into Workgroup Manager, click my Xsan volume in Sharing, and create a new folder. By default, it’s owned by the staff group, as shown in the top part of the Access panel in Workgroup Manager. The Unix-style permissions are supplemented by ACLs, not replaced by them.

Below that is the empty Access Control List, where all the action is about to take place. I have Open Directory user accounts for my editors; they are all members of a group called editors, and according to Unix they have no access to this new folder. Under the empty ACL, I click Users and Groups, select the Groups tab in the drawer, and drag the editors group into the ACL.


Click to enlarge

The entry now lets me click the arrows to adjust the group’s access. The default type, Allow, is what I want. Note that it’s just as easy to specifically deny a user access to something without having to redesign your group memberships. I’ll set the permission to Read and Write.
The inherited flag in the next column shows that this entry is not inherited from its container, but is specified right here---that’s bound to be good information once I have set ACLs at various levels of the filesystem hierarchy. Finally, the Applies To column shows that the permissions apply to the folder itself as well as all items under it now and forever. Don’t forget to click Save!


Double Check

For an even closer look, I double click the group in the ACL. This sheet lets us tweak the ACL statement. Here’s where I see that setting permissions to Read and Write will allow my editors to delete the folder itself. Not so fast! I uncheck Delete, but leave Delete Subfolders and Files so they can completely manage the folder’s contents.

When I test the new folder, I find that my editors can in fact delete the top level folder. This seems inconsistent: right there in the Access panel, Workgroup Manager reminds you that ACLs override traditional Unix permissions. The parent folder is world-writeable, though, and that folder had no ACL. Once I tighten up the parent’s Unix permissions, all is well. Lesson learned? Especially as we start to work with ACLs, it’s always a good idea to test various scenarios.

The Effective Permissions Inspector, accesesed through the little gear button at the bottom right of Workgroup Manager’s Access panel, lets you drag any user into it to look at what that user can do to the item. This munges user and group ACLs applied to the item or any container, making it easy to see the exact result of any applied policies.

CLI Corner

For those of you who do a lot of remote management or otherwise feel most at home in on the command line, several of Mac OS X’s BSD commands have been made ACL-aware. For example, ls has a new –e flag that shows extended attributes (ACLs, that is). Even if you just use the –l flag, ls displays a + to let you know that relevant ACLs exist. And for the ultimate in command-line ACL excitement, check out chmod’s man page.

MDC2:/Volumes/TEKnews/ACLS admin$ ls -eln
total 256
drwxr-x--- + 2 501  0  2048 Aug 30 16:00 Current Work
 0: group:editors allow list,add_file,search,add_subdirectory,delete_child,readattr,
 writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

ACLs are a powerful supplement to the standard Unix permissions we have grown up with, and your Xsan environment is a great place to start. Once you become comfortable with ACLs, you’ll want to use them on your file servers as well.

As with any interesting new Xsan feature, we look forward to your comments. Bring us your questions, and let us know about any quirks or tricks you find.

Comments

2
dpoves's picture

1.3 allowed LUNs over 2 TB already.

Xsan Admin 1.4 seems not to stall as much when getting updates from the
clients.

bgarner's picture

I am trying to use Xsan 1.4 with Propagating ACL permissions. The problem is that I set a group in the ACL with Full control, and then instead of the group being added to new files created (in the ACL of that new folder), my user is placed in the ACL and set to Read/Write.

Sometimes, the group for the entire Xsan Volume changed to my specific user account in the ACL window.

How can I set a group in the Volume ACL and have it propagate to every subfolder within the volume?