Permissão de pesquisa em cada diretório antes da chave

O modo 0600 e o proprietário correto não garantem que o serviço consiga abrir uma chave. A permissão em falta está normalmente num diretório acima. O Linux resolve um caminho componente a componente, e cada passo exige permissão de pesquisa antes de se tentar o seguinte. Leia o caminho inteiro, não a última linha da listagem.

A permissão de leitura é o último passo, não o único

Abrir um ficheiro exige que o kernel percorra desde a raiz ou o diretório de trabalho cada componente do caminho. Um diretório sem permissão de pesquisa interrompe essa travessia com um erro de permissão. O modo do próprio ficheiro nunca é consultado, por isso uma chave perfeitamente legível parece ilegível. O erro chega muitas vezes na abertura sem nomear o diretório, e é por isso que o ficheiro final é culpado.

Para um diretório, o bit de execução significa pesquisa, não execução do conteúdo. Uma chave continua a ser dado, e nenhuma parte desta reparação exige marcá-la como executável.

Percorra o caminho como a conta do serviço

Liste cada componente com o proprietário e o modo, e depois repita a leitura como a identidade real do serviço. A diferença entre a sua shell e o daemon é muitas vezes toda a resposta. Siga as ligações simbólicas até ao alvo real, porque é o caminho resolvido que é verificado.

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

Um serviço também pode abrir ficheiros em mais do que uma fase. Parte do material é lida durante a configuração privilegiada, enquanto outros ficheiros são abertos depois de os privilégios serem largados. Uma shell de root que lê o ficheiro não reproduz o acesso do trabalhador posterior. Um espaço de nomes de montagem pode apresentar uma vista diferente do mesmo caminho, sobretudo dentro de um contentor, por isso compare a vista do sistema de ficheiros do daemon com a sua.

Altere a permissão mais estreita que serve

Escolha a disposição mais pequena que dá acesso ao processo: um grupo controlado com pesquisa nos diretórios necessários, uma localização gerida que o serviço já possui, ou outro mecanismo documentado. Ler um ficheiro não exige permissão de escrita no seu diretório. Uma permissão ampla de escrita de grupo sobre configuração privilegiada não é uma reparação normal da travessia. O 0777 recursivo também não é solução.

Registe que componente alterou e porquê. Uma alteração de permissão sem razão registada é difícil de rever e fácil de esquecer.

Olhe para além dos modos só depois da travessia

Se os bits de modo parecerem suficientes, as verificações restantes são as ACL, a política de segurança e as restrições da sandbox. Uma ACL pode conceder acesso que os bits de modo sugerem ausente, ou negar acesso que parecem permitir. Essas definições pertencem ao atual proprietário da configuração, e devem ser ajustadas de forma estreita em vez de desligadas. Uma diferença de raiz ou de diretório de trabalho também pode explicar um caminho absoluto que funciona num contexto e falha noutro.

Não perca de vista o que é o ficheiro enquanto repara o acesso. Um certificado CA é público por conceção; uma chave privada não. Os ficheiros que o cliente reescreve também precisam de direitos de escrita diferentes dos de uma chave de identidade só de leitura. Inspecione os metadados sem imprimir segredos, e depois confirme que o serviço em si funciona após a alteração. Uma nota breve na documentação do serviço poupa a mesma travessia à pessoa seguinte.