A Complex Explanation of Unix Permissions:

In cross-platform deployments, permissions may most often be Windows-style ACLs (access control lists), allowing a wide variety of context-sensitive settings but requiring a degree of administrative overhead to set up and maintain. On native Mac OS X systems, you’ll most likely be dealing with POSIX-style permissions (also known as Unix permissions) which define file access as granted to the owner, the group, and others. This information is available for every file and folder in the Finder by highlighting an item and choosing “Get Info” in the “File” menu, then selecting “Ownership and Permissions” in the window that appears.

The underlying Unix operating system keeps track of those file permissions as numeric values, where 4 represents read, 2 represents write, and 1 represents execute (which the Finder doesn’t report). These values are additive, so that a file which allows read and write access to it’s owner and read-only access to it’s group and others is denoted as 644, with the 6 being the sum of 4 for read and 2 for write. For a directory these read and write permissions are denoted as 755 (without execute permissions a user is unable to interact with or even list directory contents, so an additional 1 is added to each position). It’s these numeric values that are used by Unix commands like chown and chmod, which change ownership and permissions mode respectively.

When you create a new file the default permissions are defined by a value called the umask. This value is subtracted from 666 for regular files (and 777 for directories) to determine their access privileges. So when creating a new folder, a umask of 022 would yield permissions of 755, allowing the owner to both read and write enclosed files while the group and others are able to read them. Unfortunately, these are the settings used by the Finder in a new OS X installation.

A Simple Way to Improve Finder Security:

By default, the Finder creates folders with permissions that allow read access to anyone who can log in to your machine. This isn’t a problem if users only save files in the pre-existing folders in their home directory (like Documents), as their permissions already prevent access by anyone but the user.

When users create additional directories, however, the documents stored inside them can be accessed by other users on that computer (or in the case of servers and when file-sharing is enabled, by anyone on the network). This is seldom the behavior that users expect, and in many settings it can present a serious security problem.

There are lots of ways to adjust the umask system-wide, depending on the OS version you’re using (such as the GlobalPreferences.plist and the NSUmask property). Unfortunately, setting the umask for the entire system is also a really good way to break things unexpectedly.

The easy way to solve this issue is to adjust the Finder’s umask settings by creating a new preferences file on the command line. So long as the files your applications save are inside folders the Finder created, you’ll have the security you need to prevent casual snooping. While logged in as an administrative user, open the Terminal and type:

defaults write /Library/Preferences/com.apple.finder \
umask -int 077

On their next login, users who create new folders in the Finder will have their permissions set automatically to 700 — allowing them to read and write the contents but preventing access by any other users entirely.

Recommended Reading: Is there anything that Wikipedia can’t explain? I’m not sure, but for more information on this topic, take a look at their excellent file system permissions entry.

In a stock Mac OS X installation, the first account created during the installation process always has administrative privileges. That first account is also always assigned the UniqueID (the number by which the operating system identifies users) of 501. Since there’s a built-in preference setting that will hide accounts with a UID below 500, changing that number with the dscl command is a good place to start.

It’s advisable to do this from the root account (where you won’t need to use sudo for the following commands), or from another administrative account created for this purpose. Open the Terminal, and type:

sudo dscl . -change /Users/ADMIN UniqueID 501 NEWUID

Change ADMIN to the name of your actual administrative user, and NEWUID to the new UniqueID number you’d like to use. While many numbers below 500 are used by the operating system, 490-499 are left unused by default.

Because we’ve changed the UID, which is used to determine ownership of files, we’ll need to make sure that any files owned by that user (especially their home directory) have their ownership changed to the new UID as well. This can be accomplished by searching for those files with the Unix find command, then changing their ownership with chown to the new UID:

sudo find / -user 501 -exec chown NEWUID {} \;

With file ownership now matching the new administrative UID, the last task is to tell the system not to display the administrative user at login or in the Fast User Switching menu. This is accomplished by editing the LoginWindow preferences file, by typing:

sudo defaults write /Library/Preferences/com.apple.loginwindow \
Hide500Users -bool TRUE

With this command, the initial administrative account will be hidden entirely, but it’s home directory will still be visible in the /Users directory. This is fine for most environments, but if you want that home directory hidden, you can move it to a hidden location and tell the OS to look there with the dscl command.

OS X keeps the root home directory in the hidden /var directory. That’s unusual for Unix, but it sets a precedent you might as well follow. To hide your administrative account’s home directory in the same manner, move it by typing:

sudo mv /Users/ADMIN /var/ADMIN

With the directory now hidden from the Finder, set its new location with:

sudo dscl . -change /Users/ADMIN NFSHomeDirectory \
/Users/ADMIN /var/ADMIN

In both these cases, change ADMIN to the name of your actual administrative user account. With this method, your administrative account should be entirely hidden from view, allowing you to keep both it’s name and it’s existence a secret from typical users.

Now this process has the potential to destroy all the data on your machine, so make sure you have a current backup of the drive you’re going to mirror and confirm the backup is both restorable and bootable. Also, if you’re mirroring your existing startup disk, you’ll need to boot off an installation DVD or external drive for the first part of the operation. But if you have a system disk that isn’t already mirrored, this procedure can save you a lot of time and frustration.

First, from the Terminal, type:

diskutil list

This will produce a listing of the attached disks, along with their types, names, sizes, and identifiers, like so:

/dev/disk1
#: type name size identifier
0: Apple_partition_scheme *465.8 GB disk1
1: Apple_partition_map 31.5 KB disk1s1
2: Apple_HFS Server Disk 465.6 GB disk1s2

Use the name of the volume you wish to mirror to find it’s identifier. If your machine only has one internal hard drive, for instance, the identifier of your boot volume will most likely be disk1s2, the second slice (after the partition scheme and map) of disk 1. Once you’ve determined which disk you’re working with, type the following, replacing IDENTIFIER appropriately:

sudo diskutil enableRAID mirror IDENTIFIER

If all goes well, the disk will unmount, reappearing in the Finder a moment later along with “The disk has been converted into a RAID” reported in the Terminal. At this point you can insert the additional disk you wish to use in the mirrored RAID array (assuming it’s not installed already), then reboot the machine off the original drive.

Now when when you run diskutil list from the Terminal you should see two new listings, one for the new virtual RAID array (the one without slice information) and the other for the additional physical disk you installed.

/dev/disk2
#: type name size identifier
0: Apple_HFS Server Disk *465.6 GB disk2
/dev/disk3
#: type name size identifier
0: GUID_partition_scheme *465.6 GB disk3
1: EFI 200.0 MB disk3s1
2: Apple_HFS New Disk 465.4 GB disk3s2

Now with the necessary identifier information, you can assign the physical disk to the mirrored RAID array, replacing RAIDARRAY with the RAID volume (in our example disk2) and NEWDISK with the hard drive being added (here disk3):

sudo diskutil addToRAID member NEWDISK RAIDARRAY &

How long the RAID mirror takes to build depends on how much data is on the original volume, but the ampersand at the end of the command tells it to run in the background. When the process is completed you’ll have two fully mirrored and redundant disks, built from your existing installation without ever having to erase the original volume.

Beginning in OS X 10.5 (Leopard), Apple built in the ability to run validity checks on any font file. Those checks can be done when the fonts are loaded into Font Book, but they’re also run beforehand when your disks are indexed by Spotlight. By using mdfind, one of the command line tools that works behind the Spotlight interface, it’s easy to find all the indexed files that may contain bad font data. Open the Terminal and type:

mdfind "com_apple_ats_font_invalid == 1"

This short and simple trick will return a list of all the suspect font files stored on any machine, whether they’re loaded in one of your user’s font folders or just stored on a spare external drive. Push the command out with Apple Remote Desktop, and you’ve got a list of every questionable font on every machine at your whole company. Once you’ve located these potential problems, it should be easy to round them up and remove them before they cause additional frustration.

Listening For Syslog Data:

Like all Unix systems, Mac OS X logs it’s system activity through syslogd, the system logging daemon. This facility keeps track of all the system activity specified in /etc/syslog.conf, which details the kind of information to log (based on its process of origin) and its level of priority (set by its parent process). This system is well documented by simply typing “man syslog” at the command line. What isn’t so easy to find is how to configure OS X clients to send this data to a central collection server for analysis.

The secret is hidden in /System/Library/LaunchDaemons/com.apple.syslogd.plist. The last item in the file is a key named NetworkListener, and by removing the comment characters around it you can tell your Mac server to listen for any and all logging information sent to it via UDP port 514. Once that’s done, you’ll need to restart the syslog mechanism by opening the Terminal and typing:

sudo launchctl unload \
/System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load \
/System/Library/LaunchDaemons/com.apple.syslogd.plist

With syslogd restarted, your server can now receive and store remote logging data from Macintosh clients, networking devices, and other Unix-compatible systems.

Sending Remote Syslog Data:

Now you’ve got a brand new syslog server. It’s listening, but nothing’s talking to it yet. For that, we’ll need to edit /etc/syslog.conf on your client machines, telling them what (and where) to report.

Open the file in any text editor, and you’ll see the following format on the very first line:

auth.info;authpriv.*;remoteauth.crit /var/log/secure.log

On the left side are a series of “selectors”, each separated by a semi-colon. Each selector is made up of a “facility” (before the period), which indicates the category being logged to, and a “level” (after the period), which indicates the level of importance that a message from that category needs to reach before it’s logged. An asterisk acts as a wildcard, including any possible facility or level.

On the right side is an “action”, preformed when syslogd receives a message matching the specified selector. This is most often expressed as a local log file, but can also be another machine listening for syslog data.

So if you wanted to log every possible message to the syslog server, you could simply add the following line (replacing server.example.com with the name of your local server):

*.* @server.example.com

That would send all that messages from any facility at any level of priority to your new syslog server. That configuration’s fine for testing a single machine, but unless your goal is to completely flood your local network with logging traffic, you’ll need to narrow down your selectors significantly before you push your revised file out to all your client machines.

Once you determine what information is important to your organization, you can build a custom syslog.conf file to install across your whole network, and begin collecting system log information for all your machines.

Recommended Reading: For in-depth information on configuring remote logging, check the manpages for syslogd, syslog, syslog.conf, and logger.

Leopard brought a number of improvements to Spotlight, the OS X search mechanism, including system-wide integration with the Finder and native applications. This is accomplished with an indexing process, mdworker, that runs in the background at all times organizing file metadata. While this feature has proven to be quite powerful, it’s also proved quite troublesome, as issues that would previously effect only Spotlight can now disable the ability to search the content of email messages and calendars as well.

When Spotlight attempts to scan a corrupt file, it can stall or crash, failing to properly index your disks and (as a result) disabling the search functionality in other Apple applications. To figure out what Spotlight’s choking on, you’ll first need it to stop indexing entirely. Make sure you’ve quit out of all your effected applications, then open the Terminal and type:

sudo mdutil -i off /Volumes/*

Once the Spotlight process is disabled, remove the old index files Spotlight built of your existing file system, replacing DISKNAME for the name of each mounted volume:

sudo rm -r /Volumes/DISKNAME/.Spotlight-V100

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 Spotlight woes.

Make sure these corrupt 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 restart Spotlight indexing:

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 your applications, and the ability to search messages and appointments should be restored.

Keep in mind that those files hold comments and folder views for the Finder, so you’ll be annoying your Mac users by disabling them. But if your own obsessive-compulsive tendencies outweigh other people’s convenience (and whose don’t?), it’s as simple as running the following command on each client machine:

sudo defaults write /Library/Preferences/com.apple.desktopservices \
DSDontWriteNetworkStores true

If you push this out with ARD, Casper Suite, or LANrev, you can leave off “sudo” as you’ll be running the command as root. Once the prefernces have changed, just reboot your machines for it to take effect. Just like magic, no more .DS_Store!

Special Thanks: It’s a beautiful lazy holiday weekend in Seattle as I write this, and there’s nothing lazier than stealing an old trick from the Creativetechs Tips blog.

Configuring Secondary DNS:

Now that you’ve got a functioning DNS server inside your network, the next thing to do is consider what happens if that server is interrupted. Once your internal DNS becomes the center of your network, it’s hard to make an argument against the importance of providing redundancy. Unless you expect your main server will never go down for even a second, you’ll want a backup plan.

Fortunately, a second OS X Server can act as a secondary DNS source with little configuration. This secondary server will provide the same information as the primary (synchronized periodically to catch any changes), and

First, on the primary server you’ve just configured, go back to the “Zones” pane in the “DNS” settings of Server Admin and highlight your domain. Then further down the window, check the box marked “Allows Zone Transfer”. With the default DNS settings Apple provides, other servers within your network should now be able to inherit and host the zone file for this domain.

Now, on the server that will act as your secondary DNS, open Server Admin, and browse to the same “Zones” pane. This should be empty on an unconfigured machine. Click the “Add Zone” button at the middle of the window, and select “Add Secondary Zone (Slave)”. Enter the domain you’ll be handling secondary DNS for, and the IP address of your primary DNS server. Save, then start the DNS server.

DNS Client Configuration:

In order to get the domain information your new servers provide, client machines need to be told where to look. And since the DNS servers at your ISP likely see an external server as authoritative for your domain, you’ll need to make sure your internal clients (including your server itself) look to the internal server first.

For a single machine, this is as easy as opening the “Network” pane of the System Preferences application and replacing the current setting with your DNS server’s IP. When you’ve got to make this change on a couple hundred machines, though, even a minute each will make for hours of work. In most cases, this means some kind of network settings deployment.

If you’re already utilizing DHCP (that’s Dynamic Host Configuration Protocol) to distribute IPs on your LAN, it makes sense to use the same mechanism to distribute DNS settings as well. If, instead, your network setup somehow precludes this, Mac OS X has an easy way to push DNS settings out to your machines. Using Apple Remote Dektop’s “Send UNIX Command” feature, just select your new client machines and enter:

networksetup -setdnsservers "NETWORKSERVICE" PRIMARY SECONDARY

In this setup, NETWORKSERVICE describes the network interface on the client machine. It’s typically “Ethernet 1″ (or just “Ethernet” for laptops), but you may wish to run networksetup -listallnetworkservices if you’ve got an unusual configuration, just to see what options are available to you. PRIMARY and SECONDARY are simply the IPs for your new DNS server(s).

This will reset the servers your client machines look to for DNS information, and allow them to find domain information specific to your internal network.

Recommended Reading: For a complete understanding of the BIND software that runs Mac OS X DNS, there isn’t a more definitive text than the venerable DNS and BIND, now in it’s fifth edition by Paul Albitz and Cricket Liu.

At the heart of this practice is a default set of user data, carefully designed around the needs of the group and applied to each account when it’s first created. For Windows that data is typically stored in C:\Documents and Settings\Default User, while Unix systems have traditionally used /etc/skel. Mac OS X keeps its user template deep within the /System hierarchy, but while finding it can be difficult, customizing it to your needs is quite easy.

Start with a new account created specifically for this purpose. Choose the system preferences, dock items, browser bookmarks, server shortcuts, and application settings appropriate to your user base, leaving out anything you can instead control via Open Directory’s managed preferences. If you install individual applications or fonts on a per-user level, include those in ~/Applications and ~/Library/Fonts (where the tilde represents the user’s home directory).

Once you’ve finished, open Keychain Access from the /Applications/Utilities folder and delete the “login” keychain (both references and files when prompted) so new users will get their own keychain file created for them. You’ll also want to delete the cache files stored in ~/Library/Caches, clear out the “Recent Items” from the Apple menu, and (if you’ve used the Terminal) discard the ~/.bash_history file.

Now log out of the template, and log in to an Admin account. From here, you’ll be clearing Apple’s existing user template and copying your new template user in its place. In Leopard, that work can’t be done using the sudo command, and instead must be preformed as the root user, meaning you run the risk of doing serious damage if you don’t understand what you’re typing. If you’re at peace with that, just open the Terminal, and very carefully type:

su -

After prompting you for a password, this will let you assume the role of root, the Unix “superuser”. This allows you to modify and delete any file on the machine.

rm -r /System/Library/User\ Template/English.lproj/*

This removes everything inside the English-speaking template folder. If you’re utilizing another language, you’ll need to change this to the appropriate template.

cp -R /Users/TEMPLATE/* /System/Library/User\ Template/English.lproj/

In the command above, replace TEMPLATE with the actual name of the template account you’ve created. This copies your prepared user environment into the template location. After which you can:

exit

Now, when you add a new user account, it’ll be created with your customizations already in place. You can then delete the original account from the install you built it on, but be sure to back up the home directory. The process can be repeated on multiple machines, deployed on your server, or incorporated into a system image, all using the same template.

Updated: This post appeared in an earlier form for Tiger back in October 2007. We thought the technique was important enough that we dragged it out of the mothballs and updated it for Leopard.

So imagine the surprise when you’ve configured and started the service, but your client machines simply won’t connect. In fact, they complain there’s a username or password error, when the username and password work fine for other services. Check the logs in Server Admin, and all you’ll find is an ominous message:

The selected logfile does not exist.

In some Leopard Server installations, the iCal Server logfiles aren’t ever created properly. The result is that the server process starts, but doesn’t do anything because it has no place to log its actions. It’s the sort of problem you’d usually figure out by digging through log files, but because they don’t exist, iCal Server just sits there dumbly, unable to provide any clues.

The easy way to stop this serpent from eating its own tail is to create and properly permission the files, then restart the iCal service. Open the Terminal, and type:

cd /var/log/caldavd/
sudo touch access.log error.log
sudo chmod 640 access.log
sudo chmod 644 error.log

The touch command creates the required logs, while chmod is used to set their permissions. With the log files now in their expected place, client machines should have no trouble connecting to iCal Server.