1

What I am trying to do but can't get to work

I am trying to set up network users in Yosemite clients with their home directories on kerberised AFP. I am using automountd to have the home directories mounted under /home/username as soon as they are accessed (ie, as soon as somebody logs in). For the most part, that works: I can login as a network user, I get a Kerberos ticket and that ticket is used for mounting the home dir. The mounting works just fine. However, the home dir will be owned by root (group: wheel), which means the user cannot access it. OS X will then ask the user for an administrator's password to "repair the user's Library".

Note that we are not running an OS X Server because the network is not Mac-only. Rather, we're running OpenLDAP and MIT Kerberos, both on Linux machines. Note also that I mostly administer Linux servers and Windows clients and I am struggling to get things right the Mac way.

What I can do to work around the problem (but our users can't)

When I first log in as a local administrator and then do (on a terminal) "su someNetworkUser", it works perfectly: The home dir is mounted with the Kerberos ticket and it is owned by someNetworkUser. I can even do that and then go back to the login window (not logging out the local admin, so the home dir does not get unmounted) and then log in as someNetworkUser: this will work perfectly because the home dir is already mounted with the correct credentials and owned by someNetworkUser. OS X will not complain about a broken library.

What I think is going on

So, apparently the first process to access /home/someNetworkUser during login via login window is owned by root. automountd will notice and mount the home dir and have it owned by root, too. I know that the login window first obtains the Kerberos ticket for someNetworkUser, otherwise the mount would fail. Apparently, things are different when using su. The first process to access /home/someNetworkUser when using su seems to be owned by someNetworkUser rather than root.

I do not quite know what processes are involved in the login process and why it's different between login window and su. I have already tried making /etc/pam.d/login (which, as I understand, is used by loginwindow) almost the same as /etc/pam.d/su - to no avail.

I also noticed that when the connection to the AFP server is lost for a moment (which I can do deliberately by restarting the AFP daemon), the home dir gets remounted when the connection is back. This time, though, the directory is owned by the correct user and not by root. That seems quite logical because at the time, it will be the user's processes that try to access the home dir, rather than root's processes.

Thoughts to seriously work around the problem

But now I'm stuck. I don't know how to make the home dirs owned by the respective user in any sensible way. I've had two ideas that I'll share but am not happy with:

  1. Create a login script that unmounts the home dir. The script would need to run as root. I would then hope that automountd remounts the dir for the user. This would be very hacky and anyway it probably would not work because the home dir will be busy at the time.
  2. Create a PAM plugin that does nothing but access the user's home dir right after pam_krb5 obtains the Kerberos ticket. Actually, it would have to wait until pam_opendirectory finds out where the user's home directory should reside; otherwise I'd have to hard-code some path, which would not be cool.

Do you have any ideas?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.