O GDM trava quando o diretório inicial está inacessível

Question

Eu configurei uma estação de trabalho OpenSUSE 12.3 com SSO através de KRB5 e LDAP.

Isso funciona muito bem até o ponto em que o GDM não está muito feliz com o fato de não poder acessar os diretórios pessoais do usuário que são, na verdade, montagens nfs com o krb5p.

Se nenhum diretório inicial estiver montado, o GDM funciona bem. Se pelo menos um diretório inicial estiver montado, o GDM irá travar ao tentar abrir a tela de saudação / login.

Se eu remover o LDAP (sss) de /etc/nsswitch.conf , o GDM funcionará bem, mesmo se os diretórios iniciais estiverem montados.

No começo eu costumava ter o nfs mount no fstab para /home/users . Há GDM iria falhar a cada vez. Então eu tentei mudar para o autofs para montar /home/users/* individualmente. Lá, o GDM funcionaria no início, mas travaria a partir de então (quando o usuário efetuasse logout). Agora eu o configurei para usar pam_mount para que os diretórios iniciais fiquem desmontados depois que um usuário fizer logout. Agora o GDM funciona desde que não haja outro usuário logado no sistema.

Portanto, o problema deve estar de alguma forma relacionado ao fato de que se o usuário gdm que o greman do GDM usa tentar acessar qualquer um dos diretórios base montados, sua permissão será negada pelo servidor nfs devido a um ticket kerberos ausente . Mesmo root não pode acessar esses diretórios.

Qualquer tentativa de fornecer acesso ao GDM a esses diretórios antes que o respectivo usuário efetue login, seria um problema de segurança.

Curiosamente, se o diretório home não existir, o GDM não terá absolutamente nenhum problema com ele. Portanto, o GDM tolera file does not exist , mas não tolera permission denied .

Portanto, isso me faz concluir que o que o GDM está tentando acessar a partir dos diretórios pessoais não é obrigatório.

Então, o que o GDM está tentando obter dos diretórios pessoais? E mais importante, como posso desativá-lo de tentar fazê-lo? Como posso evitar que isso ocorra? Alguma idéia para alguma solução extra de problemas?

Ou como posso tornar os diretórios base montados invisíveis ao GDM para que eles não tropecem neles?

    

Answer 1

Emitir com / etc / gdm / *

Ao olhar para o Manual de Referência do Gerenciador de Exibição GNOME , notei vários diretórios sob /etc/gdm com scripts diferentes e semelhantes.

Há algumas referências nesses diretórios para $HOME . Eu tentaria comentá-los para ver se você pode se livrar do acesso a $HOME .

Para depurar ainda mais seu problema, estou inclinado a lançar algumas linhas de set -x no topo dos vários scripts nesses diretórios para ver o que está sendo executado antes das mensagens de "permissões negadas".

O script nos diretórios são todos bash scripts em meus sistemas.

/etc/gdm/custom.conf

opção de depuração

Existe uma opção de depuração neste arquivo desativado por padrão . Tente ativá-lo, as mensagens serão exibidas em /var/log/messages .

[debug]
Enable=true

Desativar rostos no login

Eu também tentaria desativar a inclusão de todos os rostos do usuário em o login do gdm no navegador de rosto.

[greeter]
IncludeAll=false

Em vez de desativá-lo, você pode experimentar desativar apenas um de seus usuários problemáticos, adicionando-os a esta lista:

Exclude=<some user>

Atualização 1 - problema do bugzilla

O problema parece estar relacionado a esse bug registrado no rastreador do Red Hat Issue, intitulado:

• Bug 908337 - O GDM trava com o login krb5 e o diretório inicial do NFS4 + krb5p antes de solicitar uma senha

Não há resolução, mas como parte do bug, houve um teste para confirmar que você estava com esse bug.

Quando o problema aparece, o GDM aparentemente cria um diretório de cache aqui: /var/run/user/42 . A exclusão deste diretório permite que o login do GDM continue. O OP confirmou isso nos comentários.

Atualização # 2 - possíveis soluções alternativas

Houve um segundo comentário (por mim) de alguns links adicionais com sugestões para resolver o problema. O link intitulado:

• Como montar compartilhamentos NFS com Kerberized como um membro do CSCF Active Directory

especificamente nesta seção:

• Atualize a pilha do PAM para montar o espaço em disco NFS pessoal no logon

teve algumas modificações na configuração do PAM que podem corrigir o problema.

    

Answer 2

Uma coisa que o gdm pode procurar nos diretórios home é obter fotos dos usuários para exibição na lista de usuários.

Eu acho que o OpenSUSE usa o gdm 3.6.2, correto?

Duas coisas que eu sugiro fazer:

1. Ative o registro de depuração de acordo com debugsection do gdm , tente executar novamente o gdm e, em seguida, ver se há alguma coisa útil em seus logs do sistema
2. Tente desativar a lista de usuários conforme Configuração simples do Greeter

Answer 3

Pode estar procurando .dmrc ou algo similar para carregar as configurações de sessão do usuário. Para ter certeza, anexe ao processo do gdm com strace e verifique quais arquivos ele está tentando abrir (e onde ele trava). Você provavelmente quer usar algo como:

strace -f -o /path/to/logfile PID_OF_GDM

-f rastreia os processos filhos também, -o redireciona o log para um arquivo (instado de stderr).

Se este for o caso, colocar o arquivo no diretório do usuário antes de ele ser montado deve corrigir o problema (mas o usuário não poderá alterá-lo).

Se não for possível anexar ao GDM com facilidade antes de travar, edite o ativador (a unidade systemd apropriada ou - se você ainda estiver usando o sysvinit - o script de inicialização).

No entanto, a maneira mais segura de pegá-lo é substituir gdm por um script de wrapper que chamaria o binário original (renomeado como, por exemplo, gdm.bin ). Então, não importa como o gerente é gerado, ele será rastreado. Você também pode querer usar um arquivo com nome exclusivo para saída - use apenas $$ e / ou 'date --iso=ns' no script de wrapper:

#!/bin/bash
strace -f -o /path/to/gdm-${$}-$(date --iso-8601=ns).strace \
    /path/to/original/gdm.bin