☰

WSGI не может получить доступ к файлу, но разрешения верны

tag-icon • tag-icon linux apache-2.2 mod-wsgi wsgi strace
WSGI не может получить доступ к файлу, но разрешения верны

Я устраняю проблему, в которойMoinMoinна CentOS выдает ошибку прав доступа, но я не могу отследить, где находится проблемный файл/каталог.

Я запустил strace -vp <pid>Apache PID; когда у меня возникла проблема, я увидел следующее:

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)

Однако, поскольку Apache уже запущен, я не вижу соответствующего open()файла, указанного как 7; таким образом, я вижу проблему с правами доступа, но я все еще не знаюкоторыйПроблема в файле.

Я знаю, что могу попытаться перехватить все открываемые файлы при повторном запуске Apache, но надеюсь, что есть способ сопоставить файл 7с реальным именем файла... Есть ли способ это сделать?

ПРАВКА 1:

Следуя указаниям @lain, я запустил lsof | grep 266474069, но результаты неясны...

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

Я вижу, что это FIFO-канал, но что это значит для конфигурации моей системы? Как мне отследить первопричину проблемы EAGAIN?

ПРАВКА 2:

Благодаря @Alan Curry бег, strace -fp <pid_of_wsgi_proc>кажется, помогает мне продвинуться немного дальше...

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

Однако и Apache, и wsgiработа от имени apacheпользователя...

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

Однако, когда я запускаю следующие команды и перезапускаю Apache, я все еще не могу решить проблему...

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

Я использую это в своей конфигурации http вики:

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

решение1

Взгляните на /proc/<PID>/fdсписок всех открытых файлов, которые PIDу вас есть.

В моей системе CentOS fd 7 — это

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

Я могу затем использовать, netstat -ane | grep 1872522чтобы получить

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

Вы можете использовать

lsof | grep 266474069

чтобы получить информацию о трубе.

решение2

Глядя на свой маленький VPS, я могу определить номер fd следующим образом:

 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

[и так далее, где 17684 — это PID процесса, который я отследил ранее]

решение3

Проблема была в том, что у меня SELINUX=enforcingбыл /etc/selinux/config.

После установки SELINUX=permissiveи SELINUXTYPE=targetedперезагрузки wsgiя могу получить доступ ко всем файлам правильно.

Связанный контент