Como mapear IDs de usuário em um compartilhamento NFS?

Com todos os sistemas de arquivos de rede baseados em arquivo, as permissões de arquivo são impostas pelo servidor. O que ls -ldiz que você pode fazer com um arquivo não precisa necessariamente corresponder ao que você realmente pode fazer com esse arquivo. Por exemplo, se você usar SSHFS e autenticar como "bart", você pode fazer o cliente SSHFS reportar qualquer coisa, mas mesmo que você seja root localmente, você só terá os privilégios do usuário "bart" no servidor – a uid=opção local não teria nenhum efeito sobre o que sua conta SSHFS tem permissão para fazer.

Mas, ao contrário do SSHFS (que usa uma conexão e um conjunto de credenciais), o NFS foi originalmente projetado para ser um recurso "em todo o sistema", onde a mesma montagem pode ser usada por vários usuários diferentes, cada um com seus próprios privilégios - e foi projetado trabalhar em ambientes homogêneos em conjunto com o NIS/YP, sistema que assegurava que as mesmas contas tivessem os mesmos UIDs em todas as máquinas. A maioria dos recursos do cliente NFS (ou a falta deles) ainda refletem isso.

Portanto, com isso em mente, os UIDs têm dois usos completamente diferentes e independentes no NFS: dados de propriedade relatados pelo servidor e credenciais de autenticação relatadas pelo cliente.

• As informações de propriedade relatadas pelo servidor (como dados em ls -l) são tratadas como parte do próprio NFS.

  (É aqui que opções como uid=seriam relevantes, mas o cliente Linux NFS não as possui, embora alguns outros sistemas de arquivos as possuam.)

  No NFSv4, as informações de propriedade podem ser traduzidas usando "idmap": o servidor converte o UID em um nome de usuário@domínio, o cliente converte esse nome de usuário de volta ao seu UID local. Você precisa garantir que ambos os lados usem o mesmo domínio idmap (conforme relatado por nfsidmap -d) – se for diferente, defina-o em idmap.conf. No entanto, isso não permite que você faça nada com esse arquivo – é principalmente apenas visual.

  No NFSv3, apenas um UID numérico pode ser relatado e não há facilidade para mapeá-lo – o cliente sempre vê o UID armazenado no servidor.

• No entanto, os privilégios efetivos reais dependem das informações relatadas pelo cliente à medida que são aplicadas no lado do servidor, não apenas no lado do cliente. Isso é tratado no nível SunRPC, portanto, não há relação com as versões do NFS.

  Como o cliente NFS foi projetado para ser multiusuário, seu mecanismo de autenticação padrão é simplesmente relatar o UID do usuário que está acessando ao servidor. Portanto, se você exportar e montar o compartilhamento NFS com sec=sys(o padrão), o cliente sempre relatará seu UID real ao servidor e o servidor confiará nele sem qualquer verificação.

  Infelizmente, embora em teoria os UIDs possam ser mapeados aqui antes de reportá-los ao servidor, não existe tal recurso no cliente Linux NFS, e ele sempre relata seu UID real.

  Para resolver isso, você precisaria sincronizar o UID da sua conta em todos os sistemas ou usar a autenticação Kerberos via sec=krb5. Isso requer a configuração de um servidor Kerberos KDC.

Então, em suma,

0. Verifique se você está usando o NFS v4.

1. Execute nfsidmap -de verifique se ambos os sistemas usam o mesmo domínio idmap. Isso é por padrão adivinhado a partir do FQDN do sistema ( hostname -f), mas também pode ser definido em /etc/idmapd.conf. Esse valor não precisa ser um domínio DNS real, apenas uma string arbitrária. Isso deve corrigir o proprietário mostrado por ls.

2. Considere fortemente configurar o Kerberos, executar um KDC em seu servidor (pode ser o mesmo servidor ou um diferente) e alternar o NFS para sec=krb5. (Especialmente se você estiver usando NFS pela Internet!) Você não precisa de componentes relacionados como LDAP ou Active Directory ou IPA.

   (O mesmo Kerberos também pode ser usado para autenticação SSH via "GSSAPIAuthentication", não apenas para NFS.)

3. Se isso não for uma opção, você precisará alterar o UID da sua conta em um sistema para corresponder ao outro. Geralmente é apenas uma questão de fazer login como root e fazer usermod -u(o que também mostra todo o diretório inicial).

qual usuário você é na sua máquina local? Se você também for root, poderá editar esses arquivos. Se você é root, mas não pode editar, dê uma olhada no /etc/exportsarquivo de servidores, pois seu usuário root pode ser esmagado.

root_squash Mapeia solicitações de uid/gid 0 para o uid/gid anônimo. Observe que isso não se aplica a quaisquer outros uids ou gids que possam ser igualmente confidenciais, como bin de usuário ou equipe de grupo.

   no_root_squash
          Turn off root squashing. This option is mainly useful for
          diskless clients.

   all_squash
          Map all uids and gids to the anonymous user. Useful for
          NFS-exported public FTP directories, news spool
          directories, etc. The opposite option is no_all_squash,
          which is the default setting.

   anonuid and anongid
          These options explicitly set the uid and gid of the
          anonymous account.  This option is primarily useful for
          PC/NFS clients, where you might want all requests appear
          to be from one user. As an example, consider the export
          entry for /home/joe in the example section below, which
          maps all requests to uid 150 (which is supposedly that of
          user joe).

Além disso, você deve ter os mesmos IDs de usuário na máquina remota e local. Mas não há soluções de fácil manutenção para uso doméstico disponíveis.

Caso você NÃO seja root, não deve haver como arquivar seu objetivo, pois ninguém deve ter permissão para editar os arquivos do root em uma máquina remota!