especificando permissões complexas em arquivos e pastas no unix

especificando permissões complexas em arquivos e pastas no unix

No trabalho gerencio um grupo responsável pela gestão e segurança de dados. Precisamos especificar permissões complexas em arquivos e pastas além do usuário/grupo/mundo rwx padrão. A pesquisa mostra que isso pode ser feito com atributos de arquivo estendidos (comandos setfacl, getfacl) em arquivadores executando NFSv4. Os arquivadores em funcionamento estão executando o NFSv3. Sempre que pergunto ao grupo de TI sobre a conversão, eles sempre respondem "é muito lento, muito difícil, não é seguro ou estável, etc." atualizar para o NFSv4 sem fornecer dados ou cronogramas para fundamentar as afirmações. Como resultado, acabamos criando várias cópias de dados onde o diretórioA possui arquivos que o grupoA pode visualizar e o diretórioB possui arquivos que o grupoB pode visualizar.

Fiquei me perguntando algumas coisas:

  1. as afirmações são verdadeiras? A conversão de NFSv3 para NFSv4 com atributos de arquivo estendidos ativados afeta severamente o desempenho? existem outros itens a serem considerados? por exemplo, presumo que alguns aplicativos podem não estar codificados para interpretar adequadamente esses atributos de arquivo estendidos.
  2. Além dos acls no NFSv4, existe outra solução ou método para aplicar permissões complexas? a maioria das máquinas em funcionamento executa SLES11 ou SLES12.

Agradeço qualquer ajuda ou orientação que você possa oferecer... obrigado!

Responder1

O NFS 4 pode ser muito mais seguro e certamente estável, disponível desde 2003, se bem me lembro. Existem versões mais recentes também, 4.1 e 4.2. É muito fácil atualizar, se você não ativar nenhum dos recursos avançados.

  1. O desempenho pode ser um pouco melhor no nfs 3, devido ao uso do udp & tcp; nfs 4 é apenas tcp. Mas isso realmente não faz muita diferença na maioria dos cenários. Na verdade isso pode ser compensado, pois no tcp quando os pacotes são perdidos apenas esses pacotes perdidos são retransmitidos, ao contrário do udp. Há também delegação no nfs 4, que pode melhorar o desempenho. A criptografia pode impactar muito o desempenho, mas isso é uma escolha, não é obrigatório usar padrões de segurança mais elevados no nfs 4, mas eles estão disponíveis se necessário.
    Eu realmente não posso dizer sobre incompatibilidades de aplicativos usando o nfs v4. Eu o usei para operações de cópia e movimentação de arquivos e streaming de vídeo sem problemas.

  2. Não posso dar uma resposta definitiva sobre isso, embora eu ache que a ausência de alternativas deu origem ao nfs v4. SMB/CIFS poderiam ser usados; Não considero uma alternativa nativa por ser um protocolo Windows, mas a implementação do UNIX/Linux é excelente. Embora eu suponha que seria um desafio maior implementá-lo em servidores e clientes Linux do que o nfs v4.

Um motivo pelo qual sua equipe de TI está relutante em mudar para a versão 4 pode ser a compatibilidade e o suporte do sistema operacional: tanto os servidores quanto os clientes devem suportá-la. Talvez existam sistemas operacionais mais antigos, SLES 11 sem SPs, por exemplo, que não são suportados pelo SuSE e preferem evitar alterar as configurações neles.

Também existe a opção de compartilhar usando nfs v3 e v4. Você pode testá-lo em alguns diretórios antes de mudar totalmente para a v4.

informação relacionada