|Mac OS X 10.4 added the ability to set and respect ACLs to the OS. In general this has been a boon for Mac sysadmins, but have you ever tried to use the Finder to view the contents of a folder that has a large amount of ACLs to evaluate? The process is a painful one involving long pinwheels and Finder crashes.|
It's clear this is a Finder issue as other tools can browse the directories without any delays at all. (I have a bug open on this issue. Radar# 4209575 if anyone wants to reference it.) As Mac OS X continues to be integrated into more institutional and enterprise environments the inability for the Finder to deal with large amounts of ACLs in any given directory becomes a impediment to it's acceptance. This issue has reared it's head in a particularly savage way when dealing with Active Directory integration. Here is why it happens and one solution to a common issue.
First I want to make clear that I am not attacking the AD plugin. I, along with many others, believe that it is the single OS component that has enabled Macs to be purchased, installed, and integrated at a great many institutions. The Finder however has often been a favorite target and this article is no exception. On with the story...
One of the coolest features of the AD plugin is it's ability to lookup the AD home of a user and mount it via SMB or AFP. The home share can either be mounted as a network home or the entire share can be mounted on the Desktop and the home folder is placed in the Dock. All of this is done by simply reading the AD profile for the user at login time and then injecting some MCX to take care of the rest. There is a problem though when implemented on the Desktop and since this is the most common way to deal with the AD homes it has bitten a lot of people.
When Mac OS X mounts the home it can't mount a folder inside a share, it needs to mount the whole share and then let the user navigate to the home folder. This is why the home is placed in the dock. The problem is that if you have a lot of user's homes in that share then the Finder will fall over if you ever open that share. Just the simple act of getting info on the mount icon or just selecting it can hang your machine for a long time. While admins might be able to remember not to touch the share, a regular user will not.
So far I've seen four common solutions.
1. Purchase Thursby's ADmitMac since it can be set to mount the folder directly.
2. Create a share for each user's home. (Mac OS X Server actually has a setting to do this with SMB.)
3. Install EZIP and use it's ability to only present the user's particular home over AFP.
4. Just give up on AD network homes.
All of these solutions either cost money, are a pain, or are just not acceptable.
There is a better way.
The solution I came up with is pretty simple. When you look at the issue the simplest solution would be to prevent the user from clicking on the home share. So the real question is, how do we hide that share? The answer is to take over the home share mounting duties from the AD plugin. That way we can mount it wherever we want and hide it from prying eyes. Tiger makes all of this really easy to do because of launchd.
There are three files needed to make all of this work.
The first is a launchd job that we can run as a user launch agent. Since launch agents run in the context of the user logging in and that means that we can use their TGT to mount the home share with the correct credentials.
The second is a shell script that can decode the user's information, mount the share in mountpoint at /tmp, then symlink the user's individual home folder onto their Desktop, and finally unload the launch agent so that it will run at the next login.
The final item is a logout hook that will make sure that the home share is unmounted and the mountpoint is removed. This way any other users that login on that Mac won't run into trouble.
To the user this procedure is transparent. All they see is their home folder on their Desktop and they can access it without the Finder crashing. The only real risk would be if they Command clicked on the proxy folder when in the home and navigated back to the home share. Luckily, not too many users will try this. There is a gotcha though...
Because we have taken the home mounting duties away from the OS we have also broken home syncing. If you aren't using this feature then you won't care, but if you want it you will. I really don't think this is too big of an issue though as without some sort of workaround like this the odds were not good that your SMB homes would even work in the first place. The only other issue I can think of is that FUS might break as a result of this as well. I really don't know of too many people using that on public machines though.
You can download the files from our repository using this link. They are pretty simple to understand and all are well commented. The only real config change you should need to make will be to point the launchd job at the homemount.sh script.
I hope these help someone out and let us know if you have any trouble with the scripts.