Estou fornecendo um servidor NFS como parte de um projeto colaborativo com outro grupo que produz software cliente sobre o qual não tenho controle. Seu software fornece gerenciamento de arquivos para seus usuários através de uma interface web e serviço, e como um back-end de armazenamento, ele usa o sistema de arquivos subjacente, para o qual queremos começar a usar o NFS.
Eles vêm desenvolvendo até agora um sistema de arquivos local e, agora que estão experimentando o servidor NFS, estão descobrindo que não podem atribuir o recurso CAP_CHOWN a seu programa. Eu não encontrei uma maneira de ativar isso, mas eu também não encontrei uma razão documentada que isso é impossível.
A alternativa óbvia é executar a operação chown como raiz, de uma forma ou de outra, já que exportar o sistema de arquivos para sua máquina com no_root_squash não é uma preocupação nesta situação. No entanto, eles (compreensivelmente) não querem executar seu serviço da web como root, portanto, suponho que um kludge seria criar um binário SUID chown no cliente e ter esse chamado de seu serviço da web.
Outra alternativa pode ser mapear o usuário do aplicativo para o usuário raiz no servidor NFS, como se ele estivesse operando como root no cliente. Isso parece estranho do ponto de vista da segurança, mas parece-me um ganho líquido. Mas é um pouco estranho no lado do servidor, do ponto de vista da sustentabilidade. Além disso, não sei se isso é possível; Eu li apenas a página idmapd.conf(5) man e duvido que este seja um caso de uso que foi considerado originalmente. Pode ser explicitamente proibido.
Continuo analisando isso e, se encontrar algo, atualizarei isso, mas se alguém tiver algumas sugestões ou puder me esclarecer sobre capabilities(7) trabalhando com nfsd(8) , agradeço.
Atualização # 1: Ao verificar se há alguma ACE granular (entrada de controle de acesso) nas ACLs NFSv4 que precisem ser soltas, descobri que há uma permissão o que permite a propriedade. Isso é promissor, mas ainda estou tentando fazer com que isso funcione: no meu sistema, pelo menos (Ubuntu 16.04) ele é aceito sintaticamente, mas não aplicado e não tem efeito:
[test-nfs] nfs4_setfacl -a A::OWNER@:o testfile
[test-nfs] nfs4_getfacl testfile
A::OWNER@:tTcCy
A::GROUP@:tcy
A::EVERYONE@:tcy
[test-nfs] nfs4_setfacl -a A::OWNER@:r testfile
[test-nfs] nfs4_getfacl testfile
A::OWNER@:rtTcCy
A::GROUP@:tcy
A::EVERYONE@:tcy
Eu mexo com algumas opções de montagem / exportação no cliente e no servidor, mas ainda não consegui que isso funcione.
Atualização nº 2: De acordo com este tópico , não há como o CAP_CHOWN ser comunicado do cliente para o servidor e, portanto, não tem efeito sobre as montagens do NFS.
Estou tentando determinar se a permissão de propriedade da ACL do NFSv4 deve funcionar e o que estou perdendo aqui.
Atualização # 3: De acordo com o mesmo thread acima, a permissão para propriedade em ACLs do NFSv4 não pode ser representada corretamente usando ACLs POSIX e, portanto, requer um conjunto de ACL mais rico. Houve um trabalho de desenvolvimento sobre isso , que aparentemente parou.
Não parece que eu possa fazer o que eu quero fazer com o software como está, e o SUlKlus mencionado acima é necessário, ou algo assim para que a operação de mudança de propriedade seja efetuada como root.
A abordagem imapd.conf(5) da qual eu não gostei, mas que tentei de qualquer maneira, é impossível porque o mapeamento de ID estático só se aplica a um contexto de segurança do Kerberos, que não estou usando.
Então, não há praticamente nenhuma resposta para essa pergunta, eu não acho.