Procure em /var/log/messages e /var/log/audit/audit.log (se você tiver auditd em execução). Você também pode usar audit2allow para ver mensagens de erro do SELinux e possíveis soluções.
Eu tenho o que (deveria) ser uma tarefa bastante simples: Migre um conjunto de arquivos de log personalizados para um banco de dados à noite.
Eu uso o logrotate (cron.daily) com uma simples tarefa de pré-rotação
/var/log/myapplog/*.log
{
daily
copytruncate
rotate 366
dateext
dateformat .%Y-%m-%d
compress
missingok
compresscmd /usr/bin/xz
compressoptions -ze9
compressext .xz
prerotate
/usr/local/myapp/bin/DBWriter $1
endscript
}
Infelizmente, o SELinux não vê dessa maneira. Se eu setenforce 0 , o script é executado perfeitamente. Gira os logs, envia-os para o DB, etc.
setenforce 1 , no entanto, retorna:
logrotate_script: line 1: /usr/local/myapp/bin/DBWriter: Permission denied
Eu tentei mudar contextos no DBWriter, mais recentemente eu configurei para unconfined_u:unconfined_r:unconfined_t , o que não funcionou ...
Idealmente, preciso manter o SELinux ativado. Se for importante, o DBWriter também está disponível como um arquivo java .jar. Mas executar java -jar DBWriter.jar tem o mesmo resultado.
Obrigado antecipadamente!
Editar: a resposta da Win.T abaixo resolveu o problema para mim.
semanage permissive -a logrotate_t
Parte do problema é que eu estava tentando fazer exatamente o que o SELinux foi projetado para prevenir: fazer com que o processo A execute um arquivo desconhecido B e causar estragos no sistema C
Considerações e restrições do design do projeto nos colocam nesse caminho.
Os clientes nem sempre querem ouvir sobre essas palavras de fantasia, como segurança e proteção do futuro.