☰

WSGI no puede acceder a un archivo, pero los permisos son correctos

tag-icon • tag-icon linux apache-2.2 mod-wsgi wsgi strace
WSGI no puede acceder a un archivo, pero los permisos son correctos

Estoy depurando un problema dondeMoinMoinen CentOS arroja un error de permisos, pero no puedo localizar dónde está el archivo/directorio problemático.

Corrí strace -vp <pid>con el pid de Apache; cuando tengo el problema veo esto:

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)

Sin embargo, dado que Apache ya se está ejecutando, no veo ninguna correspondencia open()en el archivo denominado 7; entonces veo el problema de permisos, pero todavía no lo sécualEl archivo es el problema.

Sé que podría intentar capturar todos los archivos abiertos cuando reaparezco Apache, pero espero que haya una manera de asignar el archivo 7a un nombre de archivo real... ¿hay alguna manera de hacer esto?

EDITAR 1:

Usando la guía de @lain, ejecuté lsof | grep 266474069, pero los resultados no están 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]#

Veo que se trata de una tubería FIFO, pero ¿qué significa esto para la configuración de mi sistema? ¿Cómo puedo rastrear la causa raíz del EAGAINproblema?

EDITAR 2:

Gracias a @Alan Curry, correr strace -fp <pid_of_wsgi_proc>parece llevarme un poco más lejos...

[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)

Sin embargo, tanto Apache como wsgiejecutarse como apacheusuario...

[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]#

Sin embargo, cuando ejecuto los siguientes comandos y reinicio Apache, todavía no puedo solucionar el 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/

Estoy usando esto en mi configuración http de 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>

Respuesta1

Eche un vistazo a /proc/<PID>/fdlo que debería enumerar todos los archivos abiertos que PIDse han abierto.

En mi sistema CentOS, fd 7 es

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

Luego puedo usar netstat -ane | grep 1872522para obtener

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

Puedes usar

lsof | grep 266474069

para obtener información sobre la tubería.

Respuesta2

Mirando mi pequeño VPS, puedo determinar el número fd de la siguiente manera:

 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

[y así sucesivamente, donde 17684 es el PID del proceso que rastreé anteriormente]

Respuesta3

El problema era que tenía SELINUX=enforcingen /etc/selinux/config.

Después de configurar SELINUX=permissive, SELINUXTYPE=targetedy reiniciar wsgipuedo acceder a todos los archivos correctamente.

información relacionada