O log cresce mas não pode ser recriado: verifique a ACL do diretório

Um log que continua a crescer para de crescer no momento em que algo o recria, e o erro diz permissão negada. A conclusão tentadora é que o próprio arquivo de log precisa de mais permissões, mas o arquivo pode já ser gravável pela mesma conta. Acrescentar a um nome existente e criar um novo nome são duas verificações diferentes, e só a segunda consulta o diretório.

Acrescentar e criar são verificações diferentes

Abrir um arquivo existente para acrescentar exige acesso de escrita nesse arquivo e acesso de pesquisa em cada diretório do seu caminho. Criar um arquivo exige escrita e pesquisa no diretório que o contém, porque a operação acrescenta-lhe um nome. Substituir um arquivo por meio de renomeação também afeta os dois diretórios e as suas regras de sticky bit.

Um descritor já aberto acrescenta um quarto caso. Um processo pode manter um identificador de escrita aberto antes de largar privilégios e ainda assim falhar ao reabrir o mesmo caminho sob a sua identidade posterior. As adições bem-sucedidas e a criação falhada podem ambas ser verdadeiras, no mesmo momento, para o mesmo processo.

ACLs padrão herdam-se, não concedem

Uma entrada que começa com o prefixo padrão descreve o que os novos objetos herdam do diretório. Não concede nada ao próprio diretório, e não repara a ACL de um arquivo que já existe.

namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.log

Leia as entradas de acesso separadamente das padrão, e leia a máscara. Uma entrada nomeada que lista direitos completos pode ainda ser limitada pela máscara, por isso o comentário efetivo importa mais do que as letras da primeira linha.

Use o caminho resolvido em vez do caminho na configuração. Um link simbólico, um ponto de montagem ou um diretório rodado podem colocar o arquivo real onde a permissão que concedeu nunca chega. Percorra o caminho primeiro com a ferramenta de nomes, depois compare cada nível com a conta em questão. Adivinhar o diretório de topo é como uma correção aterra um nível demasiado acima.

Identifique quem escreve naquele momento

Verifique a unidade de serviço, os respetivos drop-ins e as definições da conta do próprio daemon antes de mudar algo. O processo que acrescenta e o processo que recria podem ser diferentes: um auxiliar de rotação, um escritor de estado e um leitor web raramente partilham uma identidade.

Um teste executado a partir de uma shell root não reproduz um serviço restrito, e terá sucesso enquanto o serviço continua a falhar. Reproduza a operação falhada sob a mesma unidade, com a mesma conta e as mesmas definições de sandbox. Se não conseguir, inicie a unidade com uma shell temporária e verifique a identidade que ela relata. Qualquer outra coisa mede o seu terminal, não o serviço.

Se a criação for realmente necessária, conceda ao escritor acesso ao diretório de log dedicado e mantenha o acesso de leitura para os consumidores separado. Tornar uma conta partilhada ou toda a árvore da aplicação gravável para satisfazer uma única chamada de registo troca um problema pequeno por um grande.

Rode sem reintroduzir o problema

Quem recria o arquivo decide o proprietário e o modo para o ciclo seguinte, por isso coordene a correção com a configuração de rotação. Uma substituição criada noutra conta, ou com uma ACL nova, traz a falha de volta após uma correção bem-sucedida.

Defina o modo e o grupo na criação, não depois, e verifique a rotação seguinte em vez da adição seguinte. Uma adição apenas repete o teste que já passou. Se a ferramenta de rotação oferecer uma definição de modo de criação, use-a em vez de um chmod após a criação. O intervalo entre a criação e o chmod é exatamente quando a escrita seguinte pode falhar.

Quando o truncamento falha de qualquer forma, pare de acrescentar permissões

A falha ao truncar um arquivo que pode escrever não se explica pelas permissões do diretório, e acrescentar mais delas não ajudará. Olhe antes para os atributos e o confinamento: um atributo append-only permite escritas apenas em modo de adição, e uma montagem só de leitura ou uma sandbox de serviço podem negar uma operação que a ACL permite.

Verifique as restrições do sistema de ficheiros da unidade e as opções de montagem do caminho, depois reproduza a operação exata que falhou. Ampliar uma permissão que nunca foi consultada apenas esconde qual restrição era real. Remova uma restrição de cada vez numa unidade descartável, e reverta-a antes de mudar algo permanente.