☰

WSGI kann nicht auf eine Datei zugreifen, aber die Berechtigungen sind korrekt

tag-icon • tag-icon linux apache-2.2 mod-wsgi wsgi strace
WSGI kann nicht auf eine Datei zugreifen, aber die Berechtigungen sind korrekt

Ich debugge ein Problem, bei demMoinMoinunter CentOS wird ein Berechtigungsfehler ausgegeben, aber ich kann nicht herausfinden, wo sich die problematische Datei/das problematische Verzeichnis befindet.

Ich habe es über die Apache-PID ausgeführt strace -vp <pid>. Wenn das Problem auftritt, wird Folgendes angezeigt:

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)

Da Apache jedoch bereits läuft, sehe ich keine Entsprechung open()in der Datei mit der Bezeichnung 7; daher sehe ich das Berechtigungsproblem, weiß aber immer noch nichtwelcheDatei ist das Problem.

Ich weiß, dass ich versuchen könnte, alle Dateiöffnungen abzufangen, wenn ich Apache neu starte, aber ich hoffe, dass es eine Möglichkeit gibt, Dateien 7einem echten Dateinamen zuzuordnen ... gibt es eine Möglichkeit, dies zu tun?

BEARBEITEN 1:

Ich habe unter Anleitung von @lain ausgeführt lsof | grep 266474069, aber die Ergebnisse sind unklar …

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

Ich sehe, dass es sich um eine FIFO-Pipe handelt, aber was bedeutet das für meine Systemkonfiguration? Wie kann ich die Grundursache des EAGAINProblems ermitteln?

BEARBEITEN 2:

Dank @Alan Curry strace -fp <pid_of_wsgi_proc>komme ich mit dem Laufen anscheinend ein bisschen weiter ...

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

Allerdings werden sowohl Apache als auch wsgidie Ausführung als apacheBenutzer ... ausgeführt.

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

Doch wenn ich die folgenden Befehle ausführe und Apache neu starte, kann ich das Problem immer noch nicht beheben ...

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

Ich verwende dies in meiner Wiki-HTTP-Konfiguration:

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

Antwort1

Werfen Sie einen Blick darauf. /proc/<PID>/fdDort sollten alle geöffneten Dateien aufgelistet sein PID.

Auf meinem CentOS-System ist fd 7

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

Ich kann dann verwenden, netstat -ane | grep 1872522um zu bekommen

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

Sie können

lsof | grep 266474069

um Informationen über die Leitung zu erhalten.

Antwort2

Wenn ich meinen kleinen VPS betrachte, kann ich die FD-Nummer folgendermaßen ermitteln:

 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

[und so weiter, wobei 17684 die PID des Prozesses ist, den ich zuvor verfolgt habe]

Antwort3

Das Problem war, dass ich SELINUX=enforcingin hatte /etc/selinux/config.

Nachdem ich die Einstellungen vorgenommen und einen Neustart durchgeführt habe, SELINUX=permissivekann ich auf alle Dateien korrekt zugreifen.SELINUXTYPE=targetedwsgi

verwandte Informationen