Erro stat do log falhou: Permissão negada durante o LogRotation

Question

Depois de instalar um novo servidor CentOS 6.0, o logrotate estava funcionando perfeitamente. Então, um dia devido a um pânico no kernel, o servidor teve que ser inicializado com força e desde que a rotação do log não está girando os logs.

Então, eu fiz uma entrada cron separada para girar os logs manualmente e com força e redirecionei a saída para um arquivo de log, e obtive as seguintes linhas para cada arquivo:

rotating pattern: /home/mail3/log/popMailProcessing.log  forced from command line (60 rotations)
empty log files are rotated, old logs are removed
considering log /home/mail3/log/popMailProcessing.log
error: stat of /home/mail3/log/popMailProcessing.log failed: Permission denied

No entanto, se eu fizer um logrotation manualmente a partir da linha de comando, ele funciona perfeitamente. O comando que eu uso na linha de comando é:

logrotate -v -f /etc/logrotate.d/mail3-logs

Meu arquivo logrotate.conf é:

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

O arquivo de rotação de log que o logrotate usa via cron job é:

dateext
/home/mail3/log/pop.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/oc4j.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/incoming.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/mailpro.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/imap.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/outgoing.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/smtpout.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/retry.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/mailinglist.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/migrate.log {
        daily
        rotate 60
        copytruncate
        compress
}

Minha entrada no crontab é:

03 00 * * * root /usr/sbin/logrotate -f -v /etc/logrotate.d/mail3-logs &>> /var/log/logrotate/rotate.log

O SELinux está aplicando, e foi aplicado antes da inicialização também. O diretório onde os logs são mantidos tem a raiz como seu proprietário e o diretório tem permissões completas.

Alguma pista do que está causando a permissão de erro negado?

    

Answer 1

Suas mensagens de erro originais não fazem sentido com o que você está mostrando para o seu cron que executa o logrotate .

rotating pattern: /home/mail3/log/popMailProcessing.log  forced from command line (60 rotations)
empty log files are rotated, old logs are removed
considering log /home//log/popMailProcessing.log
error: stat of /home/mail3/log/popMailProcessing.log failed: Permission denied

O que esses caminhos estão fazendo indo para /home/mail3/log/* ? Também está faltando a linha /home//log/popMailProcessing.log ? Parece que você está mostrando apenas algumas das situações reais da sua pergunta.

Depurando o problema

Coloque esta linha em um script de shell, logrotate.sh :

#!/bin/bash
/usr/sbin/logrotate -f -v /etc/logrotate.d/mail3-logs &>> /var/log/logrotate/rotate.log

Torne-o executável e execute-o assim do cron:

03 00 * * * root strace -s 2000 -o /tmp/strace.log /path/to/logrotate.bash

Ao passar pela saída, você deve ver o que está sendo enganado pelos problemas de permissão.

EDIT # 1

Depois de conversar com o OP, ele mencionou que a técnica de depuração acima descobriu que o SELinux estava habilitado. Ele ficou perplexo a respeito de porque esse era o caso, já que ele havia desativado anteriormente com o comando setenforce 0 .

Desativar o SELinux dessa maneira só permanecerá nesse estado até a próxima reinicialização. O modo padrão para o SELinux é ditado por este arquivo no Fedora / CentOS:

$ cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#   enforcing - SELinux security policy is enforced.
#   permissive - SELinux prints warnings instead of enforcing.
#   disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
#   targeted - Only targeted network daemons are protected.
#   strict - Full SELinux protection.
SELINUXTYPE=targeted

Para desabilitar permanentemente o SELinux, você desejará alterar a linha SELINUX=.. para um dos três estados, enforcing , permissive , disabled .

Eu encorajaria você, entretanto, a tomar um tempo para entender por que o SELinux está desautorizando o acesso ao diretório em que esses arquivos de log estão, e adicionar o contexto apropriado para que o SELinux permita este acesso. O SELinux é uma parte importante do modelo de segurança em camadas que é facilitado em distribuições do Linux que fazem uso dele, e desativá-lo cegamente está removendo uma das camadas críticas.

Referências

• 45.2.7. Habilitar ou Desabilitar o Guia do Usuário do SELinux - CentOS 5
• 5.4 . Ativando e Desativando o SELinux - Guia do Usuário do Red Hat 6

Answer 2

Acho que desabilitar o SELinux não é a melhor opção. A melhor solução, na minha opinião, é criar e aplicar políticas. Aqui está um exemplo de como fazer isso para outra política link . O mesmo conceito será aplicado à política logrotate_t em vez de httpd_t, conforme descrito no link.

Veja as etapas para instalar o policycoreutils-python no link. então corra

grep logrotate /var/log/audit/audit.log | audit2why

audit2allow -a

procure por logrotate_t, é mais provável que pareça com isso

#============= logrotate_t ============== 
allow logrotate_t file_t:file getattr;

execute

audit2allow -a -M logrotate_t

semodule -i logrotate_t.pp

chcon -R -t logrotate_t /[your log file location]/*.log

    

Answer 3

Em um piscar de olhos, você pode contornar isso com:

semanage permissive -a logrotate_t

Isso é oferecido na página de manual do logrotate_selinux .

Você ainda poderá ver as mensagens (que você deve eventualmente abordar) com audit2allow .