Os diretórios home do AFP automounted são de propriedade de root (cliente OS X Yosemite, servidores Linux)

Question

O que estou tentando fazer, mas não consigo trabalhar

Estou tentando configurar usuários de rede em clientes Yosemite com seus diretórios pessoais no AFP kerberizado. Eu estou usando o automountd para ter os diretórios home montados sob / home / username assim que eles são acessados (ou seja, assim que alguém efetua login). Na maioria das vezes, isso funciona: consigo fazer o login como usuário da rede, recebo um ticket do Kerberos e esse ticket é usado para montar o diretório inicial. A montagem funciona bem. No entanto, o diretório home será de propriedade root (group: wheel), o que significa que o usuário não pode acessá-lo. O OS X perguntará ao usuário a senha do administrador para "reparar a Biblioteca do usuário".

Observe que não estamos executando um OS X Server porque a rede não é somente para Mac. Em vez disso, estamos executando o OpenLDAP e o MIT Kerberos, ambos em máquinas Linux. Note também que eu principalmente administro servidores Linux e clientes Windows e estou lutando para acertar as coisas do jeito Mac.

O que posso fazer para contornar o problema (mas nossos usuários não podem)

Quando eu primeiro faço login como administrador local e faço (em um terminal) "su someNetworkUser ", ele funciona perfeitamente: O diretório home é montado com o ticket Kerberos e é de propriedade de someNetworkUser. Eu posso até fazer isso e depois voltar para a janela de login (não sair do administrador local, para que o diretório inicial não seja desmontado) e então logar como someNetworkUser: isso funcionará perfeitamente porque o diretório home já está montado com o credenciais corretas e de propriedade de someNetworkUser. OS X não vai reclamar de uma biblioteca quebrada.

O que eu acho que está acontecendo

Portanto, aparentemente, o primeiro processo para acessar / home / someNetworkUser durante o login através da janela de login é de propriedade de root. O automountd notará e montará o diretório inicial e também o proprietário da raiz. Eu sei que a janela de login primeiro obtém o tíquete Kerberos para someNetworkUser, caso contrário, a montagem falharia. Aparentemente, as coisas são diferentes quando se usa su. O primeiro processo para acessar / home / someNetworkUser ao usar su parece ser de propriedade de someNetworkUser em vez de root.

Eu não sei exatamente quais processos estão envolvidos no processo de login e por que é diferente entre a janela de login e o su. Eu já tentei fazer /etc/pam.d/login (que, como eu entendo, é usado por loginwindow) quase o mesmo que /etc/pam.d/su - sem sucesso.

Também notei que quando a conexão com o servidor AFP é perdida por um momento (o que eu posso fazer deliberadamente reiniciando o daemon AFP), o diretório inicial é remontado quando a conexão está de volta. Desta vez, no entanto, o diretório é de propriedade do usuário correto e não da raiz. Isso parece bastante lógico, porque, no momento, serão os processos do usuário que tentam acessar o diretório home, em vez dos processos do root.

Pensamentos para trabalhar seriamente em torno do problema

Mas agora estou preso. Eu não sei como fazer com que os diretórios iniciais sejam de propriedade do respectivo usuário de qualquer maneira sensata. Eu tive duas ideias que compartilho, mas não estou feliz com:

1. Crie um script de login que desmonta o diretório inicial. O script precisaria ser executado como root. Espero, então, que o automountd remonte o diretório para o usuário. Isso seria muito hacky e, de qualquer forma, provavelmente não funcionaria, porque o diretório home estará ocupado no momento.
2. Crie um plug-in do PAM que não faça nada além de acessar o diretório inicial do usuário logo após o pam_krb5 obter o tíquete do Kerberos. Na verdade, ele teria que esperar até que o pam_opendirectory descubra onde o diretório pessoal do usuário deve residir; caso contrário, eu teria que codificar alguns caminhos, o que não seria legal.

Você tem alguma ideia?