As permissões não estão sendo efetivadas com o Kerberised NFSv4 no FreeBSD

7

Atualmente estou tentando configurar um servidor NFSv4 no FreeBSD. Eu tenho uma vasta experiência em fazer isso em outros Unices (Solaris e Linux), mas sou relativamente novo no FreeBSD.

Meu objetivo é alcançar o seguinte:

  • Arquivos servidos do sistema FreeBSD
  • O único modelo de segurança deve ser krb5p
  • Clientes são Linux (Ubuntu) e OSX

Atualmente, consegui configurar as coisas para que eu precise de um TGT válido para acessar o sistema de arquivos. Após uma tentativa de acessar esses arquivos, posso executar klist no cliente e posso ver que nfs/domainname principal foi recuperado. Isso sugere que a parte Kerberos da montagem NFS está correta.

Meu problema é que todos os acessos a clientes ainda são realizados usando o nobody user. Eu posso ver as permissões quando eu faço ls -l . Até mesmo o mapeamento de usuários funciona corretamente, mas a menos que nobody tenha permissão para fazer qualquer coisa com os arquivos, eu recebo uma permissão negada.

Aqui está um exemplo de interação do cliente (o Ubuntu neste caso, mas a mesma coisa acontece com o OSX). Neste exemplo, /export/shared/testshare é o diretório compartilhado do servidor do FreeBSD:

(alterei o nome do domínio real para domain e o nome da região do Kerberos para REALM )

$ kinit
Password for elias@REALM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
$ sudo mount -t nfs4 -osec=krb5p,vers=4 lion:/export/shared/testshare /mnt
$ ls -l /mnt
total 4
-rw-r--r-- 1 nobody nogroup   5 Feb  7 18:17 bar.txt
-rw------- 1 elias  nogroup   4 Feb  5 23:09 foo.txt
$ cat /mnt/bar.txt
blah
$ echo foo >>/mnt/bar.txt
bash: /mnt/bar.txt: Permission denied
$ cat /mnt/foo.txt
cat: /mnt/foo.txt: Permission denied
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
09/02/2013 09:41:56  10/02/2013 09:40:44  nfs/lion.domain@REALM

Configuração do servidor

Eu tive alguns problemas em encontrar um guia completo para configurar o NFSv4 no FreeBSD. Isso é um pouco surpreendente por si mesmo, pois descobri que as informações sobre como fazer as coisas no FreeBSD são muito boas.

Aqui estão as linhas relevantes em /etc/rc.conf :

rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfscbd_enable="YES"
mountd_enable="YES"
gssd_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
zfs_enable="YES"

Aqui está o conteúdo de /etc/exports :

/export/shared/testshare -sec=krb5p
V4: / -sec=krb5p

Outro aspecto interessante é que, quando usei tcpdump para registrar o tráfego de rede NFS entre o cliente e o servidor, vi pacotes NFS3 junto com os pacotes NFS4 . Ambos os tipos de pacotes continham dados criptografados, então eu ainda acho que o Kerberos foi usado, mas dada a configuração acima, eu esperava que não houvesse nada além do tráfego do NFS4.

    
por Elias Mårtenson 09.02.2013 / 05:58

3 respostas

0

Eu resolvi o problema. Depois de passar pelo código, descobri que a causa era um bug na biblioteca do GSS. O problema foi causado por um buffer enviado para getpwnam_r que era muito pequeno.

Todos os detalhes podem ser encontrados na discussão na lista de e-mails

    
por 21.02.2013 / 03:21
0
  1. Precisa desativar o nfs3 com vfs.nfsd.server_min_nfsvers=4 .
  2. Para evitar "nobody", o cliente e servidor NFSv4 devem estar no mesmo domínio domain .
por 15.02.2013 / 00:20
0

Simplificando, tem que haver alguma maneira de mapear nomes de usuários entre os sistemas. Você está executando o idmapd no servidor e no cliente? Ldap?

Pelo menos como um teste, tente fazer mapeamentos específicos entre os nomes ... além do root, pelo menos inicialmente.

    
por 16.02.2013 / 01:18