O dono da pasta de sessão do php continua mudando

Question

Problema

A cada poucas semanas, a pasta de sessão do php de uma máquina muda para o proprietário apache , embora eu esteja usando o nginx. Isso quebra os aplicativos PHP, por exemplo, phpMyAdmin, com um session_start(): open(SESSION_FILE, O_RDWR) failed: Permission denied (13) -Error.

Posso consertar isso manualmente, emitindo sudo chown -R nginx /var/lib/php/session/

Ambiente

• Máquina virtual com o CentOS Linux versão 7.4.1708, yum-cron com instalação automática de atualização de segurança ativada
• Repositório do EPEL instalado
• versão nginx: nginx / 1.14.0
• versão do php: 7.0.29 (PHP-FPM)

Detalhes adicionais

• Isso parece quebrar a cada poucas semanas, no entanto, não sei dizer exatamente desde que não usamos esse PMA diariamente. No entanto, ele quebrou esta semana, e em /var/log/yum.log eu posso ver que o nginx foi atualizado esta semana: %código%
• Não consigo encontrar menção ao usuário Apr 18 04:35:53 Aktualisiert: nginx.x86_64 1:1.14.0-1.el7_4.ngx no meu apache .
• Enquanto estiver quebrado, as permissões da pasta são: /etc/php.ini

Pergunta

Por que atualizações automáticas do nginx mudam o proprietário da pasta de sessão do php, quebrando assim meus aplicativos?

    

Answer 1

existem várias maneiras de abordar esse problema

pesquisa de pacotes

Se um pacote for suspeito de causar alguma alteração, inspecione os pacotes para ver se algum deles possui o arquivo em questão; O RPM contém uma seção %files que detalha quais arquivos um determinado pacote é autoritativo. Isso pode ser consultado com rpm -ql . Por exemplo, uma força bruta para descobrir qual pacote (se houver) possui o /etc/passwd :

$ rpm -qa | while read p; do rpm -ql $p | grep -q /etc/passwd && echo $p; done
setup-2.8.71-9.el7.noarch

Este método, no entanto, não encontrará arquivos que sejam indiretamente modificados por um pacote; O RPM contém scripts que podem executar ações arbitrárias (ou chamar outros bits arbitrários de código que realizam a mudança sendo procurada). Esses scripts podem ser listados com rpm -q --scripts e, em seguida, esse código é inspecionado. Isso pode ajudar a limitar a pesquisa apenas aos pacotes recentemente instalados (verifique os registros de quais deles são), pois pode haver muito código para examinar.

depuração do kernel

O kernel linux oferece vários recursos de depuração baseados em kernel que podem ser instruídos a informar se algo toca em um determinado arquivo. Com este método, o código adequado para SystemTap ou sysdig ou o que seria configurado, e então você esperaria que isso informasse qual processo modificou o arquivo. Por exemplo, com sysdig se algo estiver modificando um diretório no qual você está interessado:

# sysdig "fd.directory contains /var/lib/php"

deve mostrar detalhes (que podem ser configurados com o -p flag) em chamadas do sistema envolvendo esse diretório. Esse comando precisará ser deixado em algum lugar, possivelmente em uma sessão tmux ou como um serviço personalizado, para que seja iniciado automaticamente até que o código incorreto possa ser encontrado. (Além disso, você pode precisar limitar a saída de depuração, pois a depuração do kernel pode produzir grandes quantidades de informações se a pesquisa for muito ampla e o comando permanecer em execução por longos períodos de tempo.)