Problema com pam_mount sshfs e pastas iniciais como pontos de montagem

2

Estou tentando usar o pam_mount para montar a pasta inicial de cada usuário em sshfs quando cada usuário faz o login. O problema em que fiquei preso é que quando o pam_mount chama mount.fuse e mount.fuse usa o ssh para montar a pasta sshfs cria o "~ / .ssh". Isso significa que o ponto de montagem de ~ / para esse usuário se torna não vazio e a montagem falha. Neste ponto, você pode apontar que existe uma opção chamada nonempty que eu posso ativar, o que permitirá a montagem em um ponto de montagem não vazio. Eu liguei isso, mas não funciona. Talvez isso seja apenas quebrado na minha versão do sshfs? Talvez eu tenha entendido errado o significado dessa opção?

Você pode perguntar, como eu sei que a montagem está falhando devido a um diretório não vazio. Eu testei minha teoria assim. Eu mudei o ponto de montagem para "~ / foobar". Então, em vez de montar diretamente no diretório home, estamos montando uma pasta chamada foobar no diretório inicial. Quando eu faço login como um usuário comum, a montagem é bem-sucedida e o diretório inicial dos usuários é montado em ~ / foobar. Então eu saio e o compartilhamento é desmontado. Então agora eu crio um arquivo em branco nesse diretório foobar para que o diretório foobar não fique vazio. Eu faço login novamente como usuário comum e a montagem falha.

Editar: Adicionadas informações de /etc/security/pam_mount.conf.xml (ip do servidor removido para privacidade)

<fusemount>mount.fuse %(VOLUME) %(MNTPT) -o %(OPTIONS)</fusemount>
<volume fstype="fuse" path="sshfs#%(USER)@<ssh server ip>:/data/home/%(USER)" mountpoint="/home/%(USER)" options="nonempty" ssh="1"/>

Edit: (a saída do audit.log no lado do servidor ssh / file)

type=CRED_DISP msg=audit(1314290438.255:1490): user pid=5817 uid=0 auid=16777308 ses=203 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="<ssh username>" exe="/usr/sbin/sshd" hostname=<client ip> addr=<client ip> terminal=ssh res=success'

Editar: Eu apenas pensei que gostaria de mencionar que eu tentei fazer basicamente o mesmo comando que o pam_mount está configurado para fazer em um diretório vazio, em seguida, um diretório não vazio. Parece funcionar quando o diretório não está vazio. Então agora minha teoria é que pam_mount não está passando a opção non_empty corretamente ou algo mais está acontecendo ... Novamente, eu não acho que é um problema de autenticação como na autenticação do lado do servidor é relatado como um sucesso. O comando de que estou falando é:

mount.fuse sshfs#<ssh user>@<ssh/file server ip>:/data/home/<ssh user> <mount point> -o "nonempty"
    
por startoftext 25.08.2011 / 17:02

1 resposta

2

Ok, eu percebi isso. Se nada for especificado em pam_mount.conf.xml para saber como montar sistemas de arquivos de fusíveis como o sshfs, então é suposto que ele seja configurado assim.

<fusemount>mount.fuse %(VOLUME) %(MNTPT) -o %(OPTIONS)</fusemount>

Então, eu não defini nada explicitamente até começar a mexer com a alteração desse padrão para fazer coisas como excluir quaisquer arquivos no ponto de montagem ou fazer o truque do ssh pensar que a casa estava em um local diferente para não criar a pasta .ssh em casa. Ambos falharam por outras razões. Por fim, defino as coisas de volta para os padrões e, em seguida, substituo o executável mount.fuse por um script bash para registrar todos os argumentos e variáveis de ambiente com os quais ele é executado. Quando fiz isso, descobri o problema. Não havia espaço entre o -o e o não vazio. Assim, como resultado, o argumento era -ononty que provavelmente causou a falha da montagem ou, pelo menos, a opção nonempty não foi aplicada. Daí o padrão, se você não especificar nada deve ser algo assim:

<fusemount>mount.fuse %(VOLUME) %(MNTPT) -o%(OPTIONS)</fusemount>

Então eu finalmente especifiquei explicitamente qual deveria ser o padrão, veja acima. E funcionou !!! Talvez isso tenha sido um bug no pam_mount. Estou executando o pam_mount-2.5-1.fc12.x86_64 no Centos6. Espero que alguém mais ache essa informação útil. Obrigado a todos que comentaram.

    
por 26.08.2011 / 02:58

Tags