OneFS: A atualização do kernel do Linux para NFS causa falhas de chamada de "acesso"

Após um upgrade do kernel Linux, as verificações de acesso que haviam sido bem-sucedidas anteriormente agora falham em diretórios nos quais o usuário de acesso não tem permissões "delete_child" em um diretório envolvido com seu fluxo de trabalho. Isso pode ser validado usando o Linux test com o comando -w sinalizar contra esse mesmo diretório; Em versões antigas do kernel, o código de retorno desse comando é 0 enquanto que em núcleos mais novos é 1.

Isso afeta os clients Red Hat e Centos que migram da versão 7 para versões mais recentes.

Essa mudança de comportamento foi introduzida no kernel v4.13-rc2 da linha principal do Linux durante uma refatoração do código do driver NFS. No entanto, aparentemente a verificação estava presente a partir do kernel principal v3.7-rc1, e não estava sendo chamada corretamente.

Após uma extensa revisão, acreditamos que tanto o novo comportamento do kernel Linux quanto o nosso comportamento estão corretos. O Linux test comando e access as chamadas do sistema são baseadas no padrão POSIX, que conceitua apenas:

• LER
• ESCREVER
• EXECUTAR

Considerando que por rfc1813#section-3.3.4 e rfc7530#section-16.1; O NFS permite permissões mais granulares e, portanto, conceitua:

• LER
• MODIFICAR
• ACRESCENTAR
• DELETE
• EXECUTAR

Com a permissão DELETE sendo definida como se um client pode Delete an existing directory entry. Isso mapeia diretamente para delete_child no OneFS, e deve ser negado em circunstâncias em que o cliente não tem essa permissão. Observe também; As permissões POSIX e NFS não correspondem exatamente. O POSIX WRITE inclui todos os conceitos nas permissões separadas de NFS MODIFY, APPEND e DELETE. Assim, quando uma ferramenta POSIX tenta verificar as permissões de "GRAVAÇÃO", o kernel do Linux está traduzindo essa solicitação de "GRAVAÇÃO" em "MODIFICAR e ANEXAR e EXCLUIR"

Finalmente, o comportamento mais recente está mais alinhado com outros drivers de sistema de arquivos do Linux que também oferecem suporte a esse conjunto de permissões. Por exemplo, o teste em um servidor de dados SMB com o mesmo conjunto de permissões também retorna uma falha ao verificar POSIX WRITE com o test usando o comando -w bandeira.
 

# Old kernel
ancons@ubuntu:~$ uname -r
4.13.0-041300rc1-generic
ancons@ubuntu:~$ sudo mount -o vers=4,proto=tcp 10.20.0.181:/ifs /mnt/nfs
ancons@ubuntu:~$ sudo mount -o user=admin,pass=a //10.20.0.181/ifs /mnt/smb
ancons@ubuntu:~$ test -w /mnt/nfs/posix; echo "$?"
0
ancons@ubuntu:~$ test -w /mnt/smb/posix; echo "$?"
1

# New kernel
ancons@ubuntu:~$ uname -r
4.14.0-041400rc4-generic
ancons@ubuntu:~$ sudo mount -o vers=4,proto=tcp 10.20.0.181:/ifs /mnt/nfs
ancons@ubuntu:~$ sudo mount -o user=admin,pass=a //10.20.0.181/ifs /mnt/smb
ancons@ubuntu:~$ test -w /mnt/nfs/posix; echo "$?"
1
ancons@ubuntu:~$ test -w /mnt/smb/posix; echo "$?"
1

Os comportamentos do OneFS e do Linux nessa circunstância estão corretos, pois os fluxos de trabalho afetados por esse problema devem fornecer o delete_child Permissão para usuários e grupos afetados. Por exemplo, se um diretório fornece acesso total ao usuário e grupo proprietário, mas remove delete_child na permissão everyone, eles podem adicionar essa permissão a todos ou podem adicionar uma ACE (Access Control Entry, entrada de controle de acesso) adicional para o usuário ou grupo que está enfrentando problemas na lista de controle de acesso (ACL) do diretamente.

# ACL that only allows root to delete child items
p980-1-1# ls -led /ifs/posix-delete_child
drwxrwxrwx +   2 root  wheel  0 Jun 18 14:20 /ifs/posix-delete_child
 OWNER: user:root
 GROUP: group:wheel
 0: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
 1: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 2: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute

# ACL that allows a specific additional group to delete child items
p980-1-1# ls -led /ifs/posix-delete_child
drwxrwxrwx +   2 root  wheel  0 Jun 18 14:20 /ifs/posix-delete_child
 OWNER: user:root
 GROUP: group:wheel
 0: group:admin allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 1: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
 2: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 3: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute

# ACL that allows everyone to delete child items
p980-1-1# ls -led /ifs/posix-delete_child
drwxrwxrwx +   2 root  wheel  0 Jun 18 14:20 /ifs/posix-delete_child
 OWNER: user:root
 GROUP: group:wheel
 0: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
 1: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 2: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child

Também é possível atualizar o kernel do Linux para reverter o comportamento. Isso requer a compilação do kernel Linux a partir do código fonte após a atualização fs/nfs/dir.c para remover o NFS4_ACCESS_DELETE requisito do NFS_MAY_WRITE macro.

Antes:

#define NFS_MAY_WRITE (NFS4_ACCESS_MODIFY | \
		NFS4_ACCESS_EXTEND | \
		NFS4_ACCESS_DELETE)

Depois:

#define NFS_MAY_WRITE (NFS4_ACCESS_MODIFY | \
		NFS4_ACCESS_EXTEND)