Zfs: Suporte NFS / POSIX ACL

Infelizmente, as coisas são um pouco mais complicadas do que parecem.

Internamente, o ZFS oferece suporte total e aplica ACLs de estilo NFS. Infelizmente, no Linux, as ferramentas existentes manipulam apenas ACLs de estilo Posix. Houve algum trabalho para trazer o modelo NFS ACL para o Linux sob o nome Rich-ACLs. Para se integrar com a nova cadeia de ferramentas Rich-ACL, o ZFS precisa fornecer uma interface virtual system.richacl xattr. Este xattr não seria armazenado como outros xattrs, mas seria integrado com zfs_getacl () e zfs_setacl (). Este gancho xattr seria responsável por traduzir um vsecattr_t de e para um fluxo linear de bytes para o xattr.

Posix ACLs podem ser facilmente suportados adicionando alguns ganchos e aproveitando as funções de suporte Posix ACL existentes. No entanto, pode ser melhor que eles não sejam implementados para evitar problemas de coerência entre Posix e Rich ACLs (NFS / ZFS).

Obrigado pela descrição. Acho que POSIX ACL também pode ser útil se houver alguns aplicativos que tenham suporte para POSIX ACLs. Pelo que me lembro o samba tem algo parecido. O rsync tem suporte para ACL, mas não tenho certeza se é apenas POSIX, porque o homem diz apenas "ACL". Não sei sobre outros aplicativos.
Só quero dizer que eles não são inúteis, mesmo com a presença de outras ACLs. E pode ser considerado para ser implementado no futuro.

Resumo do Trabalho Requerido

Internamente, o ZFS oferece suporte total e aplica ACLs de estilo NFS. Infelizmente, no Linux, as ferramentas existentes manipulam apenas ACLs de estilo Posix. Algum trabalho foi feito para trazer o modelo NFS ACL para o Linux sob o nome Rich-ACLs (pdf). Para se integrar com a nova cadeia de ferramentas Rich-ACL, o ZFS precisa fornecer uma interface virtual system.richacl xattr. Este xattr não seria armazenado como outros xattrs, mas seria integrado com zfs_getacl () e zfs_setacl (). Este gancho xattr seria responsável por traduzir um vsecattr_t de e para um fluxo linear de bytes para o xattr.

Posix ACLs podem ser facilmente suportados adicionando alguns ganchos e aproveitando as funções de suporte Posix ACL existentes. No entanto, pode ser melhor que eles não sejam implementados para evitar problemas de coerência entre Posix e Rich ACLs (NFS / ZFS).

Que tal uma opção de montagem / propriedade do sistema de arquivos sobre QUAL modelo de segurança deve ser aplicado? (e talvez o outro completamente oculto até mesmo de ferramentas de gerenciamento, como setfacl / getfacl).
No mundo Linux, Rich-ACLs quase não são usados. Posix ACLs são muito mais utilizados. Em minhas configurações típicas, a ausência de ACLs para um sistema de arquivos é um obstáculo.
Acho que desta forma podemos obter uma implementação de ACL funcional (Posix) em muito menos tempo.

Eu também gostaria de ver o suporte POSIX ACL integrado ao ZFS no Linux. Linux é POSIX, e até que RichACLs sejam mais convencionais (ou pelo menos no kernel), acho que a integração POSIX em ZFS no Linux faz sentido.

Eu adoraria ver isso incluído! Foi quase um empecilho para nós, mas decidimos viver sem ele por alguns meses.

Quando as ACLs são tratadas de forma limpa, devemos garantir que o patch a seguir para reapresentar a propriedade aclmode seja mesclado. Esta mudança já foi feita nas implementações Illumos e FreeBSD.

Problema nº 742: ressuscite a propriedade "aclmode" do ZFS
https://www.illumos.org/issues/742
https://github.com/illumos/illumos-gate/commit/a3c49ce110f325a563c245bedc4d533adddb7211

É possível mapear Posix <-> ACLs NFSv4.
A IETF tem um rascunho sobre esse mapeamento: http://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03.txt
Mas apenas especifica claramente Posix => NFSv4 (unidirecional).

Acho que a abordagem de mapeamento é teoricamente a melhor, mas é mais sujeita a erros do que outras, pois o mapeamento 1: 1 não é possível.
Sempre haverá casos em que um usuário é negado (ou pior, concedido) um privilégio que não deve ser negado (ou pior, concedido).
Pelo menos ele deve vir com um "aviso grande e gordo".
Mas não é aconselhável ter um recurso de _segurança_ que _deve_ aproximar o que deveria fazer.
Proposta: em "equívoco" NFSv4 acl não permite QUALQUER acesso e imprime erro no log do kernel.
Problema com essa proposta: os instantâneos não podem ser corrigidos manualmente.
Para defini-los não deve ser um problema, pois pode ser simplesmente visto como um formato em disco “estranho” para Posix ACLs.
Uma herança muito mais configurável de ACLs NFSv4 cria outro conjunto de problemas a serem resolvidos.

Acho que a primeira etapa dessa implementação deve ser capaz de:

• escrever ACLs POSIX, ler e aplicar o que foi escrito.
• grave-os no disco como NFSv4 ACL para que outras implementações também possam lê-los e aplicá-los conforme pretendido.
• FAIL LOUDLY com ACLs NFSv4 não trivialmente mapeáveis ​​escritas por outras implementações.
  ** negar QUALQUER acesso a esses itens.
  ** não permitindo que os usuários criem arquivos em diretórios com sinalizadores de herança "particulares"
  ** talvez tendo "comportamento de falha" configurável por sistema de arquivos com o valor padrão mais seguro. (e para instantâneos ??)

Em etapas sucessivas, a lógica de mapeamento NFSv4 => Posix pode ser ajustada e tornada muito mais personalizável.

Alguma ideia melhor?

Este parece um ponto de partida razoável para mim, apenas alguns comentários.

Embora um mapeamento 1: 1 perfeito não seja possível, as coisas não são realmente tão ruins. Como você apontou, há um mapeamento IETF Posix -> NFSv4 bem especificado que pode ser usado para definir as ACLs corretas no disco. Depois de definido no disco como um SA, a implementação zfs existente deve começar a aplicá-los independentemente dos ganchos ACL genéricos do Linux no VFS.

Obviamente, você precisará implementar algum mapeamento NFSv4 -> Posix razoável para ler as ACLs. No entanto, já existem implementações razoáveis ​​disso. Caso em questão, o servidor kernel nfs Linux que é forçado a armazenar todas as suas ACLs NFSv4 como ACLs Posix, o que é uma operação com perdas. Como um aparte, a longo prazo expor a ACL nfsv4 / zfs bruta seria uma coisa boa para o servidor kernel nfs. Você poderia evitar uma conversão NFSv4 -> Posix -> NFSv4 inútil.

Finalmente, gostaríamos de ter um conjunto de testes para verificar se acertamos. Afinal, esse é um recurso de segurança. Felizmente, é meu entendimento que já existem vários bons conjuntos de testes.

Há um trabalho em andamento sobre os richacls de Aneesh kumar, Andreas Gruenbacher sobre o trabalho anterior feito por Greg Banks. Os patches foram enviados para o 3.1 mainline mesclado., Mas devido a algumas mudanças, isso levará algum tempo e será mesclado na próxima versão.
Link para patches: - https://lkml.org/lkml/2011/10/18/279

Quando isso chegar à linha principal, podemos usá-los para oferecer suporte a nfsv4acls para ZFS.

Quando isso chegar à linha principal, podemos usá-los para oferecer suporte a nfsv4acls para ZFS.

E quanto aos ACLs POSIX? Brian disse que não é tão difícil implementá-los usinx xattr. Isso também pode ser feito por alguém, por favor. :)

ZFS suporta nfsv4acls, então IMHO devemos dar suporte para nfsv4acls primeiro e ver se acls posix são realmente necessários. Se sim, então podemos descobrir como definir um mapeamento entre eles.

Não vejo nenhuma razão para que ambos não possam ser feitos. Maxximino está atualmente trabalhando no suporte da interface system.posixacl xattr por meio de uma tradução bem documentada. A adição da interface system.richacl xattr pode ser suportada quando ela está integrada e uma cadeia de ferramentas real está disponível.

"atualmente trabalhando" conforme as tarefas acadêmicas e relacionadas ao trabalho me permitem, mas em alta prioridade para o tempo "livre".
Já examinei o código licenciado do IllumOs CDDL e encontrei alguns códigos que fazem a tradução NFSv4 <-> posix acl. Deve ser uma base sólida, do ponto de vista da correção. Detalhes sob consulta.

Eu sei que o Solaris fornece apenas duas cópias de chmod para gerenciar ACLs. Infelizmente, isso é muito estranho e desajeitado. Proponho que usemos um programa auxiliar, setzacl, getzacl ou similar para fornecer visualização ACL e facilidades de modificação em zfs no Linux. De preferência, a interface deve ser criada para ser semelhante (ou compatível com) solaris chmod, possivelmente melhorada, mas padronizada em ambas as implementações do zfs linux e, de preferência, capaz de lidar com sistemas de arquivos futuros com acls "nfs4". (Se alguém puder explicar por que eles são chamados de ACLs nfs4, também seria uma grande ajuda!)

Eu acrescentaria que os usuários do Samba podem preferir usar ACLs nfs4, pelo menos porque eles chegam mais perto de combinar ACLs NTFS do Windows, recurso por recurso. Isso é importante quando você deseja usar o Samba como um servidor para as pastas iniciais e de perfil dos usuários em um ambiente Active Directory, onde versões mais recentes do Windows verificam ACLs específicas. Além disso, a interoperabilidade do Windows era um dos objetivos de design do ZFS na época da Sun, então seria triste vê-lo ir embora ...

Dito isso, eu entendo perfeitamente a necessidade de conformidade com POSIX.

aarcane - Veja http://wiki.linux-nfs.org/wiki/index.php/ACLs para a história de NFSv4 ACLs.

No momento, estou testando um compartilhamento Samba 4 DC e ZFS CIFS; o sistema básico é o ubuntu 12.04.

Os clientes XP Pro SP3 podem ver e administrar o Active Directory (usuários e computadores) e definir as permissões NTFS corretamente em pastas compartilhadas de EXT4.

As pastas compartilhadas do ZFS tornam-se não navegáveis ​​por meio do CIFS assim que você altera suas permissões por meio da interface do XP (embora você ainda possa acessá-las - como esperado - a partir da linha de comando do servidor).

Suponho que isso seja resultado dos problemas descritos no tópico acima. Quaisquer ideias alternativas serão recebidas com gratidão.

Habilitar o administrador ACL NTFS completo por meio do Samba 4 seria um bônus enorme para o ZFS.

Você pode postar mais detalhes sobre o seu problema? Versão exata do Samba4, qual servidor de arquivos você está usando (smbd ou ntvfs) e quaisquer configurações relevantes? (por exemplo, você está usando vfs_acl_xattr ou algo semelhante?)
Talvez abra outro problema, SE a mesma configuração do Samba4 funcionar sobre extY montado sem a opção "acl".

Sobre a manipulação de ACLs NFSv4 (semelhantes a NTFS) reais por meio do Samba, isso pode ser feito _de uma maneira limpa_ somente depois que os patches "Rich ACL" forem mesclados no kernel.

Obrigado Maxximino.
Estou usando o Samba 4.0.0 alpha19.
Estou apenas tentando servidor de arquivos com ntvfs (sudo / usr / local / samba / sbin / samba -i -M single) - que serve compartilhamentos netlogon e sysvol de ext4 e meus compartilhamentos zfs de um par espelhado de unidades com aclinherit = conjunto de passagem.
Nenhum módulo vfs_acl_xattr está em uso.

"Sobre a manipulação de ACLs NFSv4 (semelhantes a NTFS) reais por meio do Samba, isso pode ser feito de uma maneira limpa somente depois que os patches" Rich ACL "forem mesclados no kernel."

Pelo que entendi, os patches oficiais do richacls suportam apenas EXT4 - você está dizendo que se eu, por exemplo, usar o opensuse (com richacls incluído por padrão) ou patch richacls para ubuntu / debian, zfs + samba4 + ntfs acls devem "começar a funcionar? "?

Eu reproduzi seu problema.
Você não está usando vfs_acl_xattr explicitamente, mas o Samba4 está fazendo a mesma coisa "silenciosamente". Ele salva suas ACLs no xattr chamado "security.NTACL" (que você pode ver com getfattr -n security.NTACL $ FILENAME; e remove com setfattr -x security.NTACL $ FILENAME).
Esse atributo é considerado apenas pelo Samba, não por nada no kernel zfs / linux. Já que um programa simples em perl que salva valores de / dev / urandom em xattrs em zfs, pode lê-los de volta sem estar corrompido, eu realmente acho que é um problema do Samba4.
O problema aparece apenas no zfs PROVAVELMENTE porque em outro fs ele pode mapear suas ACLs em ACLs Posix em vez de usar xattrs.

Não, simplesmente corrigir um kernel com patches acl ricos não é suficiente. Quando esses patches chegam à linha principal, é possível começar a integrar o suporte avançado acl no zfs.

Estou apenas construindo o Samba 4 no Suse; Acho que estava prestes a reproduzir sua reprodução de um ângulo diferente.
Me salvou da dor.

Talvez uma solução alternativa razoável (de curto prazo) seja servir arquivos do zfs por meio de um ambiente Samba 3 estável, autenticando em um Samba 4 DC em um Linux-VServer diferente, por exemplo.

A médio prazo, a utilidade de ter compartilhamentos CIFS baseados em ZFS combinados com Samba 4 AD todos baseados em um sistema operacional Linux com excelente suporte de hardware genérico _na mesma máquina_ não pode ser exagerada. Os aplicativos para pequenas empresas / sem fins lucrativos são enormes.

Obrigado por todo o trabalho até agora.

Me deparei com o seguinte tópico:
https://lists.samba.org/archive/samba/2012-August/168660.html

O resumo é que o Samba 4 tem um módulo acl chamado vfs_zfsacl, que é usado no Solaris, para que o Samba possa usar os acls nativos do ZFS. Seria possível usar este módulo com zfsonlinux? As APIs necessárias são disponibilizadas para o espaço do usuário no Linux?

@kisg Essa é uma boa pergunta, esta é a primeira vez que ouço falar do módulo vfs_zfsacl para Samba. Algumas pessoas precisarão fazer um trabalho braçal para determinar qual interface estão esperando. Dependendo do que for, poderemos fornecer. Embora, se nenhuma tradução for feita, você ainda terá o problema de não ser capaz de gerenciar as ACLs na caixa do Linux.

Dei uma olhada rápida na fonte.
Você pode encontrar a versão de branch estável do Samba v4-0 de vfs_zfsacl.c aqui: git.samba.org .

Ele simplesmente converte da representação interna do Samba para a API nativa SunOS NFSv4 acl / facl. Esta API é implementada também no FreeBSD usando um wrapper de espaço de usuário fino em torno de sua própria implementação NFSv4 acl.

Com base nessa análise, não podemos reutilizar essa implementação no Linux. Em vez disso, se a integração richacl de zfsonlinux for feita, poderíamos usar a biblioteca librichacl para criar um módulo vfs_richacl similarmente simples (esperançosamente menos de 1000 linhas) para Samba.

Do meu olhar superficial nos patches do kernel richacl, parece que a integração zfsonlinux poderia até mesmo ser feita sem realmente corrigir o kernel, apenas puxando as partes necessárias (estruturas de dados e conversão xattr) do código richacl na árvore zfs para versões do kernel que não o suporte nativamente. Isso é importante para nós, porque nós (minha empresa) gostaríamos de executar um kernel LTS padrão do Ubuntu e apenas obter o zfsonlinux como um módulo extra.

No entanto, não tenho certeza se o richacl ainda é mantido (seu repositório não é realmente atualizado) e se está a caminho de ser incluído no kernel vanilla.

Procurei o autor do patchset richacl. Ele me indicou o seguinte módulo experimental richacl vfs: v4acls-experimental / samba.git

Portanto, parece que quase todas as peças estão no lugar (ou pelo menos existem na forma experimental), exceto para o suporte a richacl no próprio zfs.

Talvez portar libsunacl.c para o Linux possa ser suficiente do lado do samba?

http://sourceforge.net/projects/libsunacl/

mas, tanto quanto eu entendo, "aclmode" ainda estará faltando no zfsonlinux.

Eu nem sei porque não temos algum tipo de suporte ACL ainda. Porque tem
zfs acls não foi ligado? Eu sei o código para um chmod e um ls
exist.a getfacl style getzacl já deveria ter sido fornecido. Tenho certeza
há uma boa razão para a falta de acls.
Em 15 de fevereiro de 2013, 14h07, "franx" [email protected] escreveu:

Talvez portar libsunacl.c para o Linux possa ser suficiente do lado do samba?

http://sourceforge.net/projects/libsunacl/

mas, tanto quanto eu entendo, "aclmode" ainda estará faltando no zfsonlinux.

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/170#issuecomment -13630736.

zfs acl é compatível
teste:
crie um arquivo em um compartilhamento smb em outro sistema de arquivos com a opção de montagem acl habilitada, defina ACL no Windows.

mova esse arquivo em um volume zfsonlinux com aclinherit = passthrough
acls são preservados ..

O que o atm não tem solução é mandar fazer no samba ..

nenhum dos acl_xattr ou acl_tdb funciona corretamente sob tal configuração, no bsd eles usam o vfs_zfsacl

através da libsunacl que se parece com um tradutor do zfs2bsd

Minha pergunta pode ser idiota, mas eu quero ter um entendimento claro se temos suporte ACL ou não. Eu criei o servidor VBox ubuntu minimal 12.04 LTS, do que instalei o ubuntu-zfs, criei os comandos pool w

História para 'mypool':
15/05/2013: 12: 49 zpool create -f mypool / dev / disk / by-id / ata-VBOX_HARDDISK_VB88a04e0d-d8d1e7a4

História para 'tanque':
2013-04-30.13: 44: 54 zpool create tank / root / vol1
2013-05-01.00: 13: 33 zfs set aclinherit = tanque de passagem
13-05-2013: 50: 14 zfs set dedup = on tank

tank suporta setfacl sem problemas
mypool NÃO, e diz que a operação não é compatível.

Quero usar zfs com samba e preciso controlar o acesso de vários usuários às pastas. Curtiu isso
root @ server : ~ # setfacl -mg: USUÁRIOS : --- test4v007 /

Eu quero implementar o patch richacls para ZFS, mas como sou totalmente inexperiente com ZFS, seria bom se um dos desenvolvedores do ZFSonLinux pudesse fornecer alguma ajuda (principalmente na forma de dicas e discussões).

Eu gostaria de dar um solavanco ...

@behlendorf - Agora que você tem uma versão estável do sistema de arquivos, temos uma escala de tempo sólida para quando isso será concluído? Eu sei que você conseguiu o marco 0.8, mas no ritmo de lançamento atual, parece que ainda faltam alguns anos - podemos antecipá-lo de alguma forma?

Queremos avançar no trabalho de implantação de nossos servidores NAS de armazenamento de perfis com Samba, mas não ter ACLs pode significar que temos que ficar com o FreeBSD, o que realmente não queremos, já que toda a nossa base de experiência é com Linux.

Espero que não seja totalmente offtopic.
Você já experimentou o Debian kFreebsd?

É quase como uma espécie de Linux ..

@sopmot - Você sabe, eu olhei para isso antes e

Bom grito, obrigado por me colocar no caminho certo - Desculpas pela grosseria.

Eu continuo olhando para kfreebsd, e está faltando iscsi, nfsv4 e um
equivalente à virtualização kvm. Eu estava falando sério sobre usá-lo como root
até que essas deficiências se tornassem aparentes
Em 19 de maio de 2013, às 9h50, "Tamas Papp" [email protected] escreveu:

Espero que não seja totalmente offtopic.
Você já experimentou o Debian kFreebsd?

É quase como uma espécie de Linux ..

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/170#issuecomment -18120673
.

Eu também adoraria ver isso endereçado. Infelizmente estou com pouco tempo hoje em dia (além disso, não sei nada sobre coisas de baixo nível / kernel), então não posso fazer muito para ajudar a mim mesmo :( Sério, estou apenas procurando uma boa maneira de aplicar certas permissões para novos arquivos em certos diretórios; muitas vezes coloco arquivos em uma pasta disponível publicamente e seria bom se eles pudessem ser configurados automaticamente com permissões relaxadas, já que eu realmente não quero definir meu umask para algo assim liberal para a maioria dos arquivos que eu crio, que acabam na minha pasta de início. No OSOL / FreeBSD, eu faria isso usando ACLs NFSv4, embora eu esteja aberto a soluções melhores se alguém tiver alguma idéia. A única outra coisa que posso pensar de está executando um cronjob que define recursivamente as perms nos diretórios relevantes a cada meia hora ou algo assim, mas isso é terrivelmente deselegante!

Para sua informação, para que as pessoas não cometam o mesmo erro que eu - Debian kFreeBSD é ótimo para suporte ZFS, mas as ACLs ainda não funcionam no userland, você apenas obtém "Função não implementada" - consulte o bug do Debian: http: // bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573

@iamacarpet Pode acontecer assim que alguém que precisa dessa funcionalidade tiver tempo para trabalhar nela. Atualmente, os principais impulsionadores do projeto não têm muita utilidade para ACLs, portanto, estão no final da lista de prioridades. Mas não há nada que impeça alguém que precisa desse apoio de entrar e fazer isso mais cedo. Desculpe, mas é apenas a realidade da situação.

Olá,

usamos zfsonlinux em um dispositivo de backup e achamos que as ACLs são importantes para fins de integração. Algumas operações comuns, como alterar as permissões em um volume compartilhado ZFS de um computador Windows, são necessárias.

O ACL ainda está no roteiro?

Obrigado.

@ n1mh Está programado para a versão 0.8.0.

Graças a @maxximino, o suporte para Posix ACLs foi implementado. Abri a solicitação pull # 1809 com uma versão quase final do patch que está pronta para testes mais amplos. Ele passa sem problemas na seção ACL do Posix Test Suite e não temos conhecimento de quaisquer problemas pendentes.

Para aqueles que desejam esta funcionalidade, seria muito útil se você pudesse testar o patch proposto com uma carga de trabalho realista. Verifique se ele se comporta conforme o esperado em seu ambiente. Posix ACLs são desabilitados por padrão, mas podem ser habilitados configurando a propriedade _acltype_ no conjunto de dados.

zfs set acltype=posixacl pool/dataset

As ACLs Posix do estilo Linux foram implementadas como um xattr e mescladas com o master. Eles são armazenados independentemente das ACLs NFS nativas e não entrarão em conflito. A nova propriedade do conjunto de dados acltype foi adicionada para habilitar essa funcionalidade. Para obter o melhor desempenho, é altamente recomendável definir acltype = posixacl e xattr = sa . Para obter mais detalhes, consulte a página de manual atualizada:

       acltype=noacl | posixacl

           Controls  whether  ACLs  are  enabled and if so what type of ACL to
           use.  When a file system has the acltype property set to noacl (the
           default)  then  ACLs are disabled.  Setting the acltype property to
           posixacl indicates Posix ACLs should be used.  Posix ACLs are  spe-
           cific  to  Linux  and are not functional on other platforms.  Posix
           ACLs are stored as an xattr and therefore will  not  overwrite  any
           existing ZFS/NFSv4 ACLs which may be set.  Currently only posixacls
           are supported on Linux.

           To obtain the best performance  when  setting  posixacl  users  are
           strongly encouraged to set the xattr=sa property.  This will result
           in the Posix ACL being stored more efficiently on disk.  But  as  a
           consequence of this all new xattrs will only be accessable from ZFS
           implementations which support the xattr=sa property.  See the xattr
           property for more details.