Recálculo de herança ACL no FreeBSD - quando isso acontece e posso forçar o recálculo de herança em vez de configurar ACLs explícitas?

Question

Se eu estou usando ACLs NFSv4 no FreeBSD, e eu mudo as ACLs em um diretório de uma maneira que afeta as ACLs herdadas de seus arquivos filhos + dirs (e potencialmente podem cascatear e afetar os filhos / netos de seus diretórios filhos ), em que momento é feito o recálculo e como o processo é gerenciado?

Exemplo concreto: suponha que eu tenha uma hierarquia de dirs existente e desejo adicionar uma nova ACL que adicione uma negação ou remova uma permissão a algum grupo. Eu executo um dos seguintes comandos para o diretório de nível superior:

• setfacl -a 0 g:mygroup:dD:fd:deny /path_to_dir
• setfacl -x g:mygroup:dD:fd:allow /path_to_dir

Mas não está claro como a propagação da ACL funciona, quando ela realmente ocorre ou até mesmo se isso acontece (ou precisa acontecer) nos documentos. Além disso, se os arquivos forem copiados com as ACLs incorretas, não consigo encontrar uma maneira de recalcular as ACLs do pai ou mesmo se isso existe.

Minhas perguntas sobre este exemplo:

1. É simplesmente executar um comando setfacl suficiente para acionar a propagação dessas regras e (se necessário) "desmembrá-las" na hierarquia , fazendo com que as permissões / ACLs em todos os objetos contidos sejam atualizadas?
2. Alternativamente, é desnecessário o recálculo do tempo de execução durante o comando setfacl , talvez porque o FreeBSD calcule ACLs "on the fly" do diretório superior para baixo durante qualquer acesso de arquivo , em vez de calcular e armazenar preventivamente ACLs efetivas e atualizá-los para todos os objetos afetados sempre que as ACLs mudam?
3. Se o FreeBSD não é calculado para baixo quando o comando é executado, e não é calculado "on the fly", quando faz o novo ACL se torna efetivo a árvore , e / ou o que deve ser feito para torná-la mais efetiva abaixo da árvore?
4. Se arquivos / dirs existirem com ACLs incorretas, é a única maneira de corrigi-lo, para tornar todas as ACLs nesses arquivos explicitamente definidas (e renunciar à herança)?

Respostas que não seriam úteis:

Se a propagação é um problema e as soluções alternativas são necessárias, há algumas respostas possíveis que podem vir à mente e que realmente não respondem à pergunta (para mim). Para ajudar a focar boas respostas, estou observando-as aqui como não respondidas:

1. Estou ciente de que eu poderia definir ACLs explícitas manualmente, usando find /path_to_dir -exec setfacl para contornar qualquer problema de propagação / recálculo. Mas isso não é útil, porque significa substituir as ACLs herdadas por ACLs explícitas. Em muitos clientes (especialmente no Windows), as ACLs explícitas / herdadas têm prioridades diferentes, portanto, isso altera a maneira como as ACLs são calculadas e as ACLs que funcionavam antes podem funcionar de maneira diferente posteriormente. Muito fácil de quebrar as coisas. Também significa que as permissões de auditoria não podem apenas verificar arquivos + dirs que não estão herdando, porque muita configuração de ACL será movida para não herdada e precisará de verificação caso a caso. Basicamente "yuck":)
2. Também estou ciente de que outra possível resposta seria copiar todos os arquivos / diretórios afetados. para um novo local paralelo no mesmo sistema de arquivos, porque a cópia pode ser forçada a criar ACLs a partir do zero e essas seriam baseadas nas ACLs atuais do diretório superior. Isso não é aplicável, já que na realidade é irrealista pedir que um sistema de arquivos inteiro seja duplicado apenas para alterar uma ACL. Também é muito fácil quebrar as coisas, interromper as coisas, mexer com rsync / backups / snapshots (se estiver usando zfs com snapshots).

Eu também gostaria de continuar no FreeBSD aqui, porque sistemas diferentes provavelmente checam e atualizam acls de forma muito diferente e o sistema atual que eu preciso de uma resposta, é baseado no FreeBSD.

    

Answer 1

Há definitivamente falta de documentação sobre isso. Pelo que posso dizer, com base em minha própria experiência, é isso:

setfacl faz nada além de adicionar, modificar ou remover uma entrada de controle de acesso (ACE) para uma determinada lista de controle de acesso (ACL). Nenhuma outra ACE em qualquer outra ACL é afetada, mesmo que algumas dessas ACEs tenham sido herdadas da ACE que foi alterada. Essas outras ACEs "herdadas" permanecem inalteradas.

Uma ACE é herdada apenas no momento em que o arquivo ou diretório que a herda é criado .

Isso significa que, se você for modificar uma ACE com os bits de herança f ou d definido, será responsável por "propagar" manualmente essa alteração para qualquer coisa herdada anteriormente dela SE FOR O COMPORTAMENTO QUE VOCÊ QUER. Em alguns casos, pode não ser, o que provavelmente é o motivo pelo qual o FreeBSD não faz isso automaticamente para você.

Por exemplo:

mkdir -p test_dir
getfacl test_dir
# file: test_dir
# owner: root
# group: wheel
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
setfacl -m g:staff:read_set:fd:allow test_dir # <- CREATE NEW ACE
getfacl test_dir
# file: test_dir
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:fd-----:allow <- NEW INHERITING ACE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
mkdir -p test_dir/child_dir
getfacl test_dir/child_dir
# file: test_dir/child_dir
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:fd----I:allow <- NEW ACE INHERITED ON CREATE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
touch test_dir/child_file
getfacl test_dir/child_file 
# file: test_dir/child_file
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:------I:allow <- NEW ACE INHERITED ON CREATE
#           owner@:rw-p--aARWcCos:-------:allow
#           group@:r-----a-R-c--s:-------:allow
#        everyone@:r-----a-R-c--s:-------:allow
setfacl -m g:staff:full_set:fd:allow test_dir # <- MODIFY ACE
getfacl test_dir
# file: test_dir
# owner: root
# group: wheel
#      group:staff:rwxpDdaARWcCos:fd-----:allow <- MODIFIED INHERITING ACE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
getfacl test_dir/child_dir
# file: test_dir/child_dir
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:fd----I:allow <- DID NOT CHANGE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
getfacl test_dir/child_file 
# file: test_dir/child_file
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:------I:allow <- DID NOT CHANGE
#           owner@:rw-p--aARWcCos:-------:allow
#           group@:r-----a-R-c--s:-------:allow
#        everyone@:r-----a-R-c--s:-------:allow

# MODIFY INHERITED ACEs TO MATCH MODIFIED INHERITING ACE
setfacl -m g:staff:full_set:fdI:allow test_dir/child_dir
setfacl -m g:staff:full_set:I:allow test_dir/child_file

Então, para responder às suas perguntas:

1. setfacl não propaga nenhuma alteração para as ACEs herdadas existentes.
2. O FreeBSD não recalcula nada na hora.
3. As premissions tornam-se efetivas somente depois de serem definidas manualmente.
4. Não, você não precisa explicitar isso. Em seu cenário, você provavelmente deseja atualizar as ACEs herdadas existentes (aquelas com o conjunto de sinalizadores I ) com as mesmas modificações feitas na ACE herdada.

Dois problemas relevantes do FreeBSD que você pode querer assistir:

• link
• link