Porque é que um contentor só começa a criar ficheiros pertencentes ao root depois de uma atualização da imagem?

Um contentor pode criar ficheiros pertencentes ao root após uma atualização da imagem quando a nova imagem altera o utilizador de execução, o entrypoint ou a rotina de inicialização da propriedade.

O volume persistente pode permanecer inalterado enquanto o contentor substituto é iniciado com um UID numérico diferente ou executa brevemente uma etapa de inicialização como root. Um novo entrypoint pode criar diretórios em falta, migrar configurações, reescrever permissões ou deixar de respeitar as variáveis PUID e PGID utilizadas pela versão anterior. Compare um ficheiro anterior à atualização, um ficheiro criado no arranque e um ficheiro criado pela aplicação em execução antes de aplicar alterações recursivas de propriedade.

Comprove que a propriedade só muda depois de o contentor atualizado arrancar

Pare a stack e registe o UID numérico, o GID, o modo, as ACL e os carimbos de data/hora de um ficheiro existente e do respetivo diretório-pai. Inicie o contentor atualizado uma vez com os registos visíveis e, em seguida, inspecione o mesmo caminho e um ficheiro criado recentemente.

As chamadas de sistema chown do Linux alteram a propriedade numérica, pelo que a prova decisiva é o UID e o GID antes e depois do arranque, e não o nome de utilizador apresentado pelo anfitrião.

Se a propriedade já for root antes do arranque, a atualização não é a causa inicial. Investigue a cópia da atualização, a extração, o restauro da cópia de segurança ou o comando do administrador que escreveu os ficheiros.

Compare o utilizador da imagem antes e depois da atualização

Inspecione a configuração das imagens antiga e nova, o utilizador efetivo do contentor, o entrypoint, o comando e as notas de lançamento. Registe se a imagem passou a declarar root, uma conta com nome ou um UID numérico diferente.

A documentação do Docker indica que a instrução USER define a identidade de execução para as instruções seguintes da imagem e para o entrypoint e o comando do contentor, quando nenhuma substituição em tempo de execução a altera.

Uma imagem pode manter o mesmo nome de utilizador da aplicação e, ainda assim, alterar o respetivo UID numérico. Compare os números dentro de ambas as versões da imagem, porque os ficheiros montados a partir do anfitrião armazenam a propriedade numérica, e não o nome de utilizador da imagem.

Verifique se o novo entrypoint executa um chown recursivo

Pesquise nos registos de arranque, nas notas de lançamento, nos scripts do entrypoint e nos rastreios de processos por chown, reparação de permissões, PUID, PGID, migração de utilizadores ou inicialização de diretórios. Teste com um pequeno instantâneo ou um volume descartável.

O GNU Coreutils define o chown recursivo como uma reescrita da propriedade em toda a árvore de diretórios selecionada, o que pode fazer com que um volume existente e correto pareça mudar imediatamente após o arranque da nova imagem.

Não remova cegamente a reparação no arranque. Algumas imagens dependem dela para os diretórios criados recentemente. Prefira um sinalizador documentado para a desativar, um UID fixo para a aplicação ou um caminho de dados mais restrito, quando a imagem o suportar.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Audite as substituições de utilizador no Compose e as variáveis PUID ou PGID removidas

Compare o modelo Compose implementado antes e depois da atualização, incluindo user:, variáveis de ambiente, grupos suplementares, perfis, ficheiros de substituição e as definições armazenadas pelo gestor da stack.

O Kubernetes utiliza identidades numéricas explícitas para a execução e os volumes, ilustrando o mesmo limite dos contentores: uma substituição em tempo de execução e uma política de propriedade do volume são definições separadas que devem permanecer alinhadas.

Se a imagem antiga traduzia as variáveis PUID e PGID, mas a nova versão as removeu ou mudou de nome, as variáveis podem continuar presentes sem controlar o processo. Verifique diretamente o UID em execução.

Tenha em conta o modo rootless e o mapeamento de IDs dos namespaces de utilizadores

Registe se o Docker é executado com privilégios root, em modo rootless ou com remapeamento de namespaces de utilizadores. Compare o UID visível no contentor com o proprietário visível no anfitrião para o mesmo inode.

A Red Hat explica que os contentores rootless utilizam intervalos de UID e GID subordinados, pelo que o root do contentor não aparece necessariamente como UID 0 no anfitrião e uma atualização pode revelar um mapeamento ou modo de execução alterado.

Não faça chown recursivo de um volume rootless para root no anfitrião sem compreender o mapeamento. Isso pode tornar os dados inacessíveis à identidade pretendida do contentor.

Verifique se uma montagem idmapped ou de rede altera o proprietário visível

Identifique se os dados da aplicação estão num sistema de ficheiros local, numa montagem idmapped, NFS, SMB, FUSE ou numa partilha NAS. Registe as opções de montagem e compare a propriedade a partir do servidor, do anfitrião e do contentor.

O modelo de montagens idmapped do kernel Linux separa a propriedade do sistema de ficheiros da propriedade da montagem, pelo que o mesmo ficheiro pode aparecer com IDs diferentes sem uma reescrita física recursiva da propriedade.

Se apenas o proprietário apresentado mudar após a atualização, verifique se o runtime entra agora num namespace ou mapeamento de montagem diferente. Repare o mapeamento em vez de reescrever todos os inodes.

Restabeleça uma identidade de execução estável e verifique a atualização seguinte

Faça uma cópia de segurança dos metadados de propriedade, pare a aplicação, defina o UID e o GID numéricos pretendidos, corrija apenas os caminhos pertencentes à aplicação e reimplemente com uma imagem fixada e definições de utilizador documentadas.

O artigo da ZimaSpace sobre a propriedade dos contentores após a cópia de dados da aplicação aborda as causas relacionadas com cópias e migrações; este artigo isola uma alteração introduzida pela imagem substituta.

A reparação está concluída quando o arranque, as escritas da aplicação, a recriação do contentor, o reinício do anfitrião e uma atualização controlada da imagem criam ficheiros com a identidade documentada, sem exceções amplas de permissões.

Perguntas frequentes

Um ficheiro pertencente ao root prova que todo o contentor é executado como root?

Não. Um entrypoint pode ser executado brevemente como root para inicializar um volume e depois reduzir privilégios antes de a aplicação arrancar.

Devo executar chown recursivo em todo o volume?

Não antes de identificar o UID pretendido, os caminhos partilhados, as ACL e o mapeamento de namespaces. Uma reescrita abrangente pode danificar bases de dados, conteúdos multimédia partilhados ou a propriedade de contentores rootless.

Uma atualização da imagem pode alterar o UID da aplicação?

Sim. Os responsáveis pela manutenção podem alterar o utilizador da imagem, reconstruir a base de dados de contas, mudar o nome das definições PUID ou PGID ou adicionar uma migração de propriedade no arranque.