☰

WSGI não pode acessar um arquivo, mas as permissões estão corretas

tag-icon • tag-icon linux apache-2.2 mod-wsgi wsgi strace
WSGI não pode acessar um arquivo, mas as permissões estão corretas

Estou depurando um problema ondeMoinMoinno CentOS está gerando um erro de permissão, mas não consigo rastrear onde está o arquivo/diretório problemático.

Corri strace -vp <pid>no apache pid; quando tenho o problema eu vejo isso:

epoll_wait(10, {{EPOLLIN, {u32=3487534344, u64=140367313734920}}}, 2, 10000) = 1
accept4(6, {sa_family=AF_INET6, sin6_port=htons(52621), inet_pton
    (AF_INET6, "::ffff:105.193.30.91", &sin6_addr), sin6_flowinfo=0, 
    sin6_scope_id=0}, [28], SOCK_CLOEXEC) = 11
## Later on...
read(7, 0x7fffa658ad7f, 1)              = -1 EAGAIN (Resource temporarily 
    unavailable)

No entanto, como o Apache já está em execução, não vejo nenhuma correspondência open()no arquivo referido como 7; então vejo o problema de permissões, mas ainda não seiqualarquivo é o problema.

Eu sei que poderia tentar capturar todos os arquivos abertos quando eu reaparecer o Apache, mas espero que haja uma maneira de mapear o arquivo 7para um nome de arquivo real... existe uma maneira de fazer isso?

EDITAR 1:

Usando a orientação de @lain, executei lsof | grep 266474069, mas os resultados não são claros...

[root@lnxlmf moin]# ls -la /proc/9707/fd/7
lr-x------. 1 root root 64 Aug 28 15:39 /proc/9707/fd/7 -> pipe:[266474069]
[root@lnxlmf moin]#

[root@lnxlmf moin]# lsof | grep 266474069
httpd      9703      root    7r     FIFO                0,8          0t0  266474069 pipe
httpd      9703      root    8w     FIFO                0,8          0t0  266474069 pipe
httpd      9705    apache    7r     FIFO                0,8          0t0  266474069 pipe
httpd      9705    apache    8w     FIFO                0,8          0t0  266474069 pipe
httpd      9706    apache    7r     FIFO                0,8          0t0  266474069 pipe
httpd      9706    apache    8w     FIFO                0,8          0t0  266474069 pipe
httpd      9707    apache    7r     FIFO                0,8          0t0  266474069 pipe
httpd      9707    apache    8w     FIFO                0,8          0t0  266474069 pipe
httpd      9733    apache    7r     FIFO                0,8          0t0  266474069 pipe
httpd      9733    apache    8w     FIFO                0,8          0t0  266474069 pipe
[root@lnxlmf moin]#

Vejo que este é um canal FIFO, mas o que isso significa para a configuração do meu sistema? Como posso rastrear a causa raiz do EAGAINproblema?

EDITAR 2:

Graças a @Alan Curry, correr strace -fp <pid_of_wsgi_proc>parece me levar um pouco mais longe...

[pid  9731] stat("/opt/moin/share/moin/wikiconfig.py", {st_mode=S_IFREG|0770, st_size=6463, ...}) = 0
[pid  9731] stat("/opt/moin/share/moin/data/pages", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
[pid  9731] access("/opt/moin/share/moin/data/pages", R_OK|W_OK|X_OK) = -1 EACCES (Permission denied)

No entanto, tanto o apache quanto wsgio executado como apacheusuário ...

[root@lnxlmf moin]# ps auxw | grep -E "apache|wsgi"
apache   10187  0.0  0.1 373488  5884 ?        Sl   17:18   0:00 moin_http_wsgi
apache   10188  0.0  0.1 373488  5884 ?        Sl   17:18   0:00 moin_https_wsgi
apache   10189  0.0  0.1 185096  5824 ?        S    17:18   0:00 /usr/sbin/httpd
root     10243  0.0  0.0 103240   848 pts/1    S+   17:21   0:00 grep -E apache|wsgi
[root@lnxlmf moin]#

No entanto, quando executo os seguintes comandos e reinicio o Apache, ainda não consigo resolver o problema...

[root@lnxlmf moin]# pwd
/opt/moin/share/moin
[root@lnxlmf moin]# chown -R apache:apache data/
[root@lnxlmf moin]# sudo chmod -R ug+rwx data/
[root@lnxlmf moin]# sudo chmod -R o-rwx data/

Estou usando isso na configuração http do meu wiki:

<VirtualHost *:443>
  ServerName netwiki.foo.com
  DocumentRoot /opt/moin/share/moin
  WSGIScriptAlias / /opt/moin/share/moin/server/moin.wsgi
  WSGIDaemonProcess moin_https display-name=moin_https_wsgi \
      user=apache group=apache \
      processes=1 threads=10 maximum-requests=1000 umask=0007
  WSGIProcessGroup moin_https
  WSGIApplicationGroup %{GLOBAL}

  # Generate with...
  # openssl req -new -x509 -days 365 -nodes -out netwiki.pem -keyout netwiki.key
  SSLEngine on
  SSLCertificateFile /etc/httpd/ssl/netwiki.pem
  SSLCertificateKeyFile /etc/httpd/ssl/netwiki.key
</VirtualHost>

Responder1

Dê uma olhada no /proc/<PID>/fdque deve listar todos os arquivos abertos que PIDforam abertos.

No meu sistema CentOS fd 7 é

lrwx------. 1 root root 64 Aug 28 22:01 7 -> socket:[1872522]

Posso então usar netstat -ane | grep 1872522para obter

tcp    0  0 :::443              :::*               LISTEN      0          1872522

Você pode usar

lsof | grep 266474069

para obter informações sobre o tubo.

Responder2

Olhando para o meu pequeno VPS, posso determinar o número fd da seguinte maneira:

 ll /proc/17684/fd/ |colrm 1 46

0 -> /dev/null
1 -> /dev/null
10 -> /var/www/vhosts/censored.xenuser.org/statistics/logs/error_log
11 -> /var/www/vhosts/censored.de/statistics/logs/error_log
12 -> /var/www/vhosts/censored.org/statistics/logs/error_log 
13 -> /var/www/vhosts/xenuser.org/statistics/logs/error_log
14 -> /var/log/apache2/access.log

[e assim por diante, onde 17684 é o PID do processo que rastreei anteriormente]

Responder3

O problema é que eu tinha SELINUX=enforcingem /etc/selinux/config.

Depois de definir SELINUX=permissive, SELINUXTYPE=targetede reinicializar, wsgiposso acessar todos os arquivos corretamente.

informação relacionada