Skip to content

kerberos permission denied in OS 10.5

Experienced a weird problem with a fairly new OS 10.5 machine today.  My boss had spent the past couple weeks configuring an install of 10.5 on an external FW drive (keeping the 10.4 install on the local drive so as not to disrupt work for days on end while configuring / installing apps) and the time came for me to finaly make it live on his local drive.  So I started up his machine in target disk mode and plugged it into my computer, along with the external FW drive, fired up Carbon Copy Cloner and proceeded to clone the FW drive over his local drive.  It should be noted at this point that everything in 10.5 was working just fine while booted on the external drive up to this point.

Upon rebooting the laptop with its new fresh clone things appeared to be working but I soon discovered (upon starting Mail.app) that the machine was failing to get a kerberos ticket which was normally issued upon login.  I fired up the CLI and tried getting a ticket manually with kinit and got a strange permission denied, so I then tried the GUI Kerberos.app and received a similar permission denied message.  As I tinkered with it some more trying to get a ticket I eventually got one, at least I thought I did, I could see a ticket with klist and it showed up in Kerberos.app but the ticket didn’t work for any services.  Next I tried to destroy the ticket with kdestroy to see if I could get a ticket again, but that too failed with a ‘Permission denied’ error - now things are getting really weird.

Next up came some heavy googling, reading about Leopards new local KDC, and trying kinit in other accounts on the computer to verify the clone was good (they all worked).  

Out of options I figured I would try doing an strace on the failing programs only to learn that OS X doesn’t have strace, so some more googling I learn that OS X has ktrace, pulling my hair out trying to figure out why I can’t find ktrace I learn that ktrace got replaced with dtrace and dtruss (which is simlar to (s|k)trace) in leopard.  So now on the right path with dtruss I did a trace on (or is that a ‘truss’ ??) on kinit and found that the last files and directories it was stat’ing was in ‘/var/folders’, a directory that I have never heard of.  Doing some more searching around it appears this is some kind of cache folder for OS X and the permissions differed from what was on my leopard machine.  My computer had /var/folders with the directories underneath it being root:root, 755 - however my boss’s computer had some other groups.

So I just went for it and rm -rf’ed the directory that dtruss revealed while logged in as another local user, after all I did have a backup of the 10.4 install and the 10.5 on the FW drive.

Low and behold, upon logging in with my boss’s account after the cleanup the computer was able to get it’s tickets properly and authorize to all the services that I couldn’t before.

What and why this happened, I just don’t know - that just may be a little more than I know about OS X’s BSD sub-system.  I can only hope this post may find someone out there that was in the same situation as I was and help them to a speedy recovery.

Post a Comment

Your email is never published nor shared. Required fields are marked *