StickyBits NFSv4 ACL para parar o movimento do usuário de pastas

Question

Backstory: o cliente tem um ambiente misto de POSIX e NFSv4. O POSIX expulsa a ACL do NFSv4 subjacente toda vez que a toca ou faz qualquer coisa com ela. Eles dizem que os usuários podem pegar uma pasta e movê-la para outra pasta, embora a ACL do NFSv4 tenha o parâmetro de exclusão desativado. Como em um movimento é uma exclusão.

O cliente então tentou chmod 1755 para a pasta, mas os arquivos ainda podem ser movidos.

A ACL principal do arquivo se parece com isso:

#NFSv4 ACL
#owner:root
#group:root
special:owner@:rwxc:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED  
 (-)DELETE    (X)DELETE_CHILD (X)CHOWN        (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

special:group@:rwx-:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (X)DELETE_CHILD (-)CHOWN        (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

special:everyone@:rwx-:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (X)DELETE_CHILD (-)CHOWN        (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

Quando eu crio um diretório de teste dentro dessa pasta pai, recebo a seguinte ACL do NFSv4:

#NFSv4 ACL
#owner:root
#group:root
special:owner@:rwxc:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (X)DELETE_CHILD (X)CHOWN        (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

special:group@:r-x-:allow
 (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (-)CHOWN        (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

special:everyone@:r-x-:allow
 (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (-)CHOWN        (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

Quando eu crio um arquivo de teste dentro deste novo diretório eu recebo a seguinte ACL do NFSv4:

#NFSv4 ACL
#owner:root
#group:root
special:owner@:rw-c:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (X)CHOWN        (-)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

special:group@:r---:allow
 (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (-)CHOWN        (-)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

special:everyone@:r---:allow
 (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (-)CHOWN        (-)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

1. Encontrei o seguinte que acredito poder ajudar aplicando um bit pegajoso a um NFSv4 ACL = MODE4_SVTX Como integrar isso ao meu NFSv4 ACL existente visualmente? Depois que eu descobrir isso, posso ir em frente e empurrá-lo para baixo da árvore.

2. É o elemento filho delete na ACL permitindo que essas pastas sejam movidas para outras pastas?

O GOAL: Encontrar uma maneira de permitir que os bits fixos nas ACLs do NFSv4 impeçam outras pessoas além do proprietário daquele arquivo de mover / excluí-lo.

Informação extra:

Dois bits de máscara de acesso governam a capacidade de excluir uma entrada de diretório: ACE4_DELETE no próprio objeto (o "destino") e ACE4_DELETE_CHILD no diretório de contenção (o "pai"). Muitos sistemas também pegam o "sticky bit" (MODE4_SVTX) em um diretório para permitir a desvinculação apenas para um usuário que possui o destino ou o pai; em alguns desses sistemas a decisão também depende se o o alvo é gravável.

Os servidores DEVEM permitir a desvinculação se o ACE4_DELETE for permitido no destino, ou ACE4_DELETE_CHILD é permitido no pai. (Observe que isso é verdade mesmo se o pai ou o alvo explicitamente negar um dos essas permissões.)

Se as ACLs em questão não permitirem explicitamente nem DENY acima, e se MODE4_SVTX não estiver definido no pai, então o servidor deve permitir a remoção se e somente se ACE4_ADD_FILE é permitido. No caso em que MODE4_SVTX é definido, o servidor também pode exigir que o removedor possua o pai ou o alvo, ou pode requer que o alvo seja gravável.

Isso permite que os servidores suportem algo próximo ao tradicional UNIX semântica, com ACE4_ADD_FILE ocupando o lugar do bit de gravação.