Control File Access With ACLs

Traditional Unix file permissions (and their resultant issues and repairs) have been perplexing the majority of Macintosh users since OS X first appeared. Windows administrators, on the other hand, have bemoaned the lack of granular control in Apple's operating systems, with less-detailed permissions available than with Microsoft's XP and Vista. While Tiger introduced Windows-style ACLs (Access Control Lists) to the Macintosh, Leopard now utilizes them by default, making more complex file-sharing schemes a reality. Whether that's a gift or a curse depends on your ability to make ACLs work for you.

Understand Access Control Lists:

As easy as ACLs are to implement, deciding how to use them can be quite complicated. Access Control Lists are ordinal, meaning that the system reads them in order until it finds one that applies. Because of this, they can contain contradictory entries, with the actual permissions determined by where each entry appears in the overall list. ACLs also overrule standard file permissions, meaning that once they're utilized you can't depend on POSIX access schemes to be enforced. Without a clear plan for how your files will be shared, these features can lead to a great deal of confusion among users (if not the administrative team itself).

Mac OS X breaks ACL permissions into four groups: Administration, Read, Write, and Inheritance. "Administration" allows a user or group to change ownership and permissions. "Read" and "Write" act much like their POSIX counterparts, but allow for a much finer degree of control (such as whether or not users can read file attributes and permissions or delete files and folders as well as write to them). Finally, "Inheritance" determines if and how these permissions will be propagated to other files within a folder. Add to that the ability to allow or deny any of these rights, and you can see how a complex ACL scheme can become overwhelming.

Until you're comfortable with Access Control Lists, the best plan is to keep your plan simple. Assign "Administration" rights to a single administrative group, preferably the same group which has POSIX ownership of your share point. Then determine which user groups should have read or write access, and assign them to the list. Set these permissions at the root of your share point, and apply all inheritance options. Most importantly, avoid any "Deny" entries, which can make initial troubleshooting difficult.

Enabling Access Control Lists:

Now that you have a stragtegy to implement ACLs, you'll need to make sure that your files can apply them. If the volume was attached to your server when Leopard was installed, this should have taken place by default. If, on the other hand, you have an external volume coming from an earlier OS X installation, or you're still working on Tiger, you'll have to enable ACLs manually before you can continue. Open the Terminal and type the following, replacing DISKNAME with the name of your volume:

fsaclctl -p /Volumes/DISKNAME -e

It's important to note that in Tiger, enabling ACLs for a volume disables the ability to inherit permissions via standard POSIX (Unix-style) controls. Leopard's controls appear to allow both, but as of version 10.5.1 inheriting permissions works only when using ACLs, regardless of your settings.

Configuring Access Control Lists:

Once you've enabled ACLs, the final step is to set them for your files. In Leopard, this can be done in the "Sharing" section of Server Admin. In Tiger, similar controls can be found in Workgroup Manager.

In the top half of the window, select the share point you'd like to enforce access controls on. Then click the "plus" button on the bottom left, and the "Users and Groups" palette will appear. From the palette, you can drag the users or groups you're granting permissions into the bottom half of the main window, then arrange them in whatever order you planned. The "Permission" column will allow you to set "Full Control", "Read & Write", "Read Only", or "Write Only" from the main window. For additional options (such as removing the ability to delete files), select the "Custom" option.

Finally, if you want your existing files to have the same access controls, click the "gear" button at the bottom of the window and select "Propogate Permissions..." from the menu. When the propagation sheet appears, check the "Access Control List" box and click "OK". Those permissions will be applied to all the files beneath that share point.

With Access Control Lists in place, Windows teams can finally have the same control over their Macintosh shares, while long-time Macintosh admins can escape the pitfalls of Leopard's new file sharing issues.

Recommended Reading: John Siracusa gives a great overview of access control lists at Ars Technica, in his original review of Tiger (where they first appeared for Macintosh). Shareware author Marcel Bresink also has a great ACL overview in the manual for his application Tinker Tool. Lastly, if you're struggling with Unix permissions under Leopard, you'll want to see Apple's discussion forum for the article on 10.5 Server not inheriting permissions correctly.

Don’t Install Office 2008 (Yet)

The most frustrating part of IT work is that you can't fix every problem you find. That's certainly the case with the retail version of Office 2008 that shipped last Tuesday. The installer is fraught with serious permissions issues, and currently the best solution is to wait for a fix from Microsoft before deployment.

The good news is, the Office 2008 installer utilizes Apple's .pkg format, allowing for customization and deployment through Remote Desktop. The bad news is that the packages carry the wrong UID for installation, the UNIX identifier that determines ownership of files. In this case, that UID is 502, a user that may or may not be an administrator in business environments and likely doesn't exist on single-user systems. This presents a significant management issue, allowing an unprivileged account to accidentally delete Office 2008 on multi-user systems.

Worse still, the Office 2008 files are all set as executable, meaning that they can be run as scripts. This isn't just the applications, but the support files as well, such as templates, graphics, and documentation. The combination of these two errors could allow a malicious user to get around existing security policies.

There's no guarantee that the same issues will be present in the corporate edition of Office shipping February 1st, and it's more than likely that Microsoft will release a new installer or an update that remedies the problems. So if at all possible, the best approach is not to install the newest version of Office until these issues are resolved.

Update: On January 25th, Microsoft published some of these details in their "Office For Mac" weblog. On March 14th, they followed suit with the Office 2008 12.0.1 Update, addressing this and other bugs in the initial release.

Recommended Reading: This issue was first confirmed by Joel Bruner in his blog posts "Office 2008, 502, and you" and "Office 2008 for the executive", and publicized by John Gruber at Daring Fireball. The Microsoft Business Unit published its response in their blog entry "Security issue in Mac Office 2008 Installer".

Mail Won’t Search Messages

You're looking for an email you sent months ago. You're not sure which member of your team it went to, and you can't remember the subject line you used. You know what it was about, though, so you type that in Mail's "Search" field. When the results appear, however, the option to search through each "Entire Message" is suddenly grayed out and unavailable.

Leopard brought a number of improvements to Apple's Mail, such as integrated to-do lists, RSS feed subscriptions, and Address Book data detection. It also added the ability to perform system-wide email searches with Spotlight, the OS X file indexing engine. While this feature has proven to be the most powerful, it's also been the most troublesome, as issues that would previously effect only Spotlight can now disable the ability to search the content of email messages.

When Spotlight attempts to scan a corrupt file, it can stall or crash, failing to properly index your disks and (as a result) your Mail archives. To figure out what Spotlight's choking on, you'll first need it to stop indexing entirely. Make sure you've quit out of Mail, the open the Terminal and type:

sudo mdutil -i off /Volumes/*

Next, open the Console application in the Utilities folder. View "All Messages" in the left hand column, and use the "Filter" field in the top right to search for "mdworker" (the behind-the-scenes process that indexes data for Spotlight). If the remaining errors end in file names, you've found a likely source for your Mail woes. Make sure these files are safe to move (and not within Application bundles or required by the OS), then relocate them to a removable drive or erase them entirely.

With your suspect files out of the way, you can remove your existing Spotlight indexes and restart the process. On the command line, substitute the name of each of your mounted volumes for DISKNAME, and type:

sudo rm -r /Volumes/DISKNAME/.Spotlight-V100
sudo mdutil -E -i on /Volumes/*

Once the indexing is complete, check the Console logs again to make sure the errors haven't repeated. You can now reopen Mail, and the ability to search entire messages should be restored.

Network Time Machine

Advertised heavily and presented enticingly, every Macintosh user has heard that Time Machine takes the complexity out of backups. While that may be true for individual users, managing numerous backups over a network is still a significant challenge for most Macintosh administrators. So with all the attention paid to the Time Machine in Leopard client, there hasn't been much focus on how Leopard Server can be used to back up multiple users to remote disks. In fact, if you're not looking closely, the Time Machine features in OS X Server are easy to miss entirely.

To configure your workstations to use server-based Time Machine storage, you'll have to set up network shares. If you aren't running AFP, your first step is to turn on file sharing. Open Server Admin and select your server from the left. Click "Settings" from the toolbar, then "Services" below it, and check "AFP" from the list of services and save.

Now choose "File Sharing", then the "Volumes" view below it, and browse to the location you're assigning as your Time Machine share. Set the permissions as "Read & Write" to the group you're backing up (for a small workgroup, that could be all your users, while for larger organizations you'll likely want to split users up across a number of shares). Click the "Share" button in the upper right, and save again. With your share created, switch to the "Share Points" view, and select "Enable as Time Machine backup destination", saving one last time.

Using Bonjour, Leopard Server will broadcast the share across your local network, making it available as a Time Machine disk automatically in each machine's System Preferences. Once the user is logged in to the share, the use of a network volume is transparent to the user. On the management side, each backup is created as an individual sparse disk image, allowing portability and preventing user files from getting intermingled. Since users can delete files from these images, it's wise to back them up off the server to removable media as well.

While it isn't the answer for every environment, setting up Time Machine through OS X Server combines many of the best features of local and remote backup methods.

Manage Account Preferences

One of the long-standing complaints from IT departments about Mac OS X is the lack of a granular administration system. Users are either administrators or they aren't; It's a simple and appealing set up for home studios, but a serious problem for companies laboring under HIPAA and Sarbanes-Oxley regulation. In our earlier series on how to master Open Directory, we deployed centrally managed network accounts for Macintosh. Administrators who need finer control of the user environment can build on that deployment to manage account preferences.

Open Workgroup Manager, and select the "Preferences" button from the toolbar at the top of the window. The panel on the right will change to display the preferences available for control through Open Directory. While you can manage preferences for individual accounts, it's significantly more scalable (not to mention less confusing) to utilize groups for these purposes. Select the second button at the top of the left hand column (illustrated with three silhouettes) to do so.

Using the icons on the right, you can then choose which Applications users may or may not launch, determine their write privileges for external media, establish which System Preferences settings they can change, and more. These are the Managed Client for OS X (also known as MCX) preferences.

For most preferences, you can set the frequency to "Once" (meaning the setting is a default that can be overwritten by the user) or "Always" (meaning the user cannot change the settings at all). Many offer "Often" as well (meaning the setting is editable but reset on each login), useful for public machines but outgrown by Leopard's new Guest account. Some preferences, however, either can't be set through user groups (such as Login and Energy Saver options), or make little sense on a per-user basis (like network proxies, available printers, or Software Update). For these settings, you'll want to set machine-based preferences.

Tiger Server controls all your per-computer settings from one pane (illustrated with two overlapping boxes), where you first create each machine account then build "lists" from those accounts). Leopard Server splits computer-based management into two panes, one for individual machine accounts (illustrated by a single box) and the second now just for machine "groups".

Regardless of which system you're using, you'll create accounts by adding their name and MAC address (also called Ethernet ID). Machine accounts are also created dynamically when a computer binds to your Open Directory domain. Once your accounts are in place, you can add them to the appropriate lists (Tiger) or groups (Leopard), and manage preferences for every user on a given machine.

Combined with the locked administrative System Preferences on each workstation, managed account preferences allow administrators to truly define account policy for their Macintosh users.