OpenBSDs httpd + php + gnupg

wankka

Member
Hat schon mal jemand httpd + PHP + gnupg auf OpenBSD zum Laufen bekommen?
Ich hab ein ganz simples PHP Programm welches in der shell funktioniert,
aber unter httpd immer einen Fehler zurück gibt.
PHP:
putenv('GNUPGHOME=gnupg');
$keydata = "<my public key>";
$gpg = new gnupg();
$gpg->seterrormode(gnupg::ERROR_EXCEPTION);
$info = $gpg->import($keydata);
Und zwar schlägt der Import fehl mit der nichtssagenden Meldung "failed to import...".

Ich habe testweise die Berechtigungen für den gnupg Ordner auf 777 und
den Benutzer auf www:www gesetzt, aber ohne Erfolg.

Kann es etwas damit zu tun haben, dass es im chroot läuft bzw. das der www
Benutzer kein normaler Benutzer ist?

Ich weiß, ich hatte es mal unter Ubuntu und Apache am Laufen. Aber ich
kann mich beim besten Willen nicht mehr erinnern ob ich dafür etwas an
der Konfiguration ändern musste.

Bin für jeden Tipp dankbar!
 
Gibt es kein Logfile vom Webserver?
Was gibt die Methode geterror() zurück, nachdem du import() aufgerufen hast?

Rob
 
error.log vom Webserver:
Code:
Bei seterrormode(ERROR_EXCEPTION):
PHP message: PHP Fatal error:  Uncaught Exception: import failed in /htdocs/test.php:61
Stack trace:
#0 /htdocs/test.php(61): gnupg->import('-----BEGIN PGP ...')
#1 {main}
  thrown in /htdocs/test.php on line 61

Bei seterrormode(ERROR_WARNING):
PHP message: PHP Warning:  gnupg::import(): import failed in /htdocs/test.php on line 61
access.log vom Webserver:
Code:
default 127.0.0.1 - - [08/Apr/2019:19:09:46 +0200] "GET /test.php HTTP/1.1" 200 0
default 127.0.0.1 - - [08/Apr/2019:19:09:53 +0200] "GET /test.php HTTP/1.1" 200 0
default 127.0.0.1 - - [08/Apr/2019:19:10:53 +0200] "<UNKNOWN> " 408 0
408 soll wohl ein Timeout sein? Aber alles was ich im Script habe sind diese paar Zeilen und mein PGP Key.
Ein var_dump() von geterror() nach dem Import gibt "bool(false) " zurück, genauso aber auch ein var_dump() von $info. Ein false sollte laut Doku (bei geterror) aber Erfolg bedeuten...
 
Ich würde in so einem Fall einmal versuchen zu testen, ob der Webserver tatsächlich in dieses Verzeichnis schreiben kann (einfach mal irgend eine Datei im Ordner gnupg per file_put_contents() kreieren.

Und/oder ich würde es mal mit einem absoluten Pfad für gnupg versuchen (dann natürlich von der Chroot ausgehend), um sicher zu gehen, dass auch wirklich das Verzeichnis verwendet wird, was Du eigentlich im Sinn hattest.
 
file_put_contents() funktioniert sowohl mit einem relativen als auch mit einem absoluten Pfad zum gnupg Verzeichnis. Das Setzen von GNUPGHOME auf einen absoluten Pfad hat leider nicht geholfen.
 
Könnte es sein, dass import nur funktioniert, wenn schon ein Keyring existiert? Sprich: Musst Du den Keyring im Verzeichnis gnupg erstmal anlegen, bevor Du ihn in PHP nutzen kannst?
 
Auf der Kommandozeile ist das nicht nötig, aber ich werde es heute Abend mal ausprobieren.
Kann ich eigentlich Befehle auf der Kommandozeile als www-Benutzer ausführen? Wahrscheinlich muss ich ihm eine andere Shell eintragen als /sbin/nologin.
 
hi

ggf mal pruefen ob nicht pledge eine rolle spiel , nicht pledge software kann eigentlich , bei default mount , unter /usr/local

etwas speichern .

holger
 
So jetzt hab ich das mal ausprobiert. Es funktioniert auch nicht wenn ich zuvor über die Kommandozeile den Keyring erstellt habe.
Leider hat auch "su -m www -c 'php-7.2 test.php' auf der Kommandozeile nichts gebracht. Es hat einfach nur ein "Sorry" ausgegeben. Ich schätze da muss doch mehr gemacht werden für OpenBSD.
Wie kann ich denn feststellen ob pledge da seine Finger im Spiel hat?
Kann das am chroot liegen bzw. kann man das deaktivieren im httpd?
 
Sorry, das hab ich überlesen. Hab jetzt ein /usr/local in meinem chroot erstellt und auch GNUPGHOME angepasst, aber meinen key kann ich auch hier nicht importieren. Oder bedeutet das, es geht nur im richtigen /usr/local, also ohne chroot?
Auf der anderen Seite reden wir doch über PHP und httpd. Und mit file_put_contents() kann ich ins gnupg Verzeichnis schreiben.
 
hi

stimmt ich meinte auch diesen passus ( siehe man mount )

wxallowed Processes that ask for memory to be made writeable
plus executable using the mmap(2) and mprotect(2)
system calls are killed by default. This option
allows those processes to continue operation. It is
typically used on the /usr/local filesystem.
 
Ich hatte heute morgen noch etwas Zeit und habe in das GNUPG Plugin von PHP eine extra Ausgabe in die import Funktion eingebaut.
PHP's import ruft gpgme_op_import() auf welches als Rückgabewert 0x7000079 liefert.

Jetzt habe ich den Wert entschlüsselt aber bin nicht wirklich schlauer.
Die erste 0x7 ist wohl die Fehlerquelle GPG_ERR_SOURCE_GPGME und die 0x79 am Ende ist der eigentliche Fehler: GPG_ERR_UNSUPPORTED_PROTOCOL.

Sehr merkwürdig dass das auf der Kommandozeile funktioniert wenn doch das Protokoll nicht unterstützt wird...
Vielleicht hat noch jemand ne Idee?
 
gnupg 1.4.23 (aus den Packages). Hatte davor gnupg 2.2.10 (auch aus den Packages), aber damit liefen die Tests von gnupg 1.4.0 (PECL) nicht durch. gpgme (auch aus den Packages) ist die Version 1.10.

Die Versionen hab ich jetzt aus den FTP Package Mirrors rausgesucht. Ich werde das später zu Hause noch mal prüfen.

Ich muss jetzt auch noch mal erwähnen, dass zwei Tests nach dem Kompilieren von PECLs gnupg fehlschlugen. Bei beiden ging es aber um das Exportieren von Keys. Da ich das Feature nicht brauche habe ich das erst mal ignoriert.
 
Kann es etwas damit zu tun haben, dass es im chroot läuft bzw. das der www
Benutzer kein normaler Benutzer ist?

Das ist ja auch der Sinn eines chroot. Wenn man daraus auf das filesystem ausserhalb des chroot zugreifen koennte, waere das ja sinnlos. Es gibt meines wissens nach nur zwei Moeglichkeiten:

1. Du kopierst alle benoetigten files und libs nach "/var/www/usr/local/..." oder
2. du setzt das chroot in der "httpd.conf" auf "/" und die jeweiligen root dirs auf "/var/www/htdocs/deine_seite/".
 
Das Kompilieren der neusten gnupg Version hat nicht geholfen. Aber einen kleinen Schritt bin ich trotzdem weitergekommen!
Ich hab nämlich rausgefunden dass PHP einen eingebauten Webserver hat. Das wusste ich noch nicht!
Und wenn ich "php -S 127.0.0.1:80 -t ." in meinem htdocs Verzeichnis ausführe und mein Testprogramm starte, dann läuft mein kleines Testprogramm durch und importiert den Schlüssel!
D.h. an dieser Stelle möchte ich erstmal die gnupg, gpgme, etc. libs ausschließen.
Was übrig bleibt ist der httpd und php72_fpm.

Mein httpd.conf sieht wie folgt aus:
Code:
chroot "/var/www"

server "default" {
    listen on 127.0.0.1 port 80

    log access "access.log"
    log error "error.log"

    location "*.php" {
        fastcgi socket "/run/php-fpm.sock"
    }

    directory {
        no auto index, index "index.php"
    }
}

types {
    include "/usr/share/misc/mime.types"
}
Ich weiß leider nicht welche Files und Libs gebraucht werden, deshalb würd ich gerne erst Prüfen ob es überhaupt am chroot liegt.
Wenn ich jetzt chroot auf "/" setze, ein root "/var/www/htdocs" in den server Bereich einbaue und für den fastcgi Bereich ein "/var/www/run/php-fpm.sock" nehme, dann bekomme ich meine Seite nicht angezeigt (connection refused error im Browser).
Was übersehe ich hier?
 
Du hast recht, er läuft nicht. Aber beim Starten mit rcctl gibt er ein OK zurück...
Selbst die Debug-Ausgaben mit rcctl -d sind identisch mit denen bei einem erfolgreichen Start.

Habe jetzt rausgefunden, dass httpd ein implizites /logs vor den Pfad setzt. D.h. mein error.log und access.log würde so aussehen "/logs/var/www/logs/...".
Jetzt hab ich in meinem root ein /logs Verzeichnis erstellt damit die Pfade richtig sind und httpd aufstarten kann.
Zusätzlich musste ich in meiner /etc/php-fpm.d/default.conf den chroot Eintrag auch auf / setzen damit PHP Dateien gefunden/ausgeführt werden konnten.

Habe mein Test-Skript nach / kopiert und ein /gnupg Verzeichnis erstellt (777, www:www) und das Test-Skript aufgerufen. Selbes Ergebnis: Import failed...

Eigentlich sollte nach dem Umstellen des chroot auf / Zugriff auf alles libs möglich sein. D.h. das chroot muss ich jetzt auch mal ausschließen.

Jetzt frage ich mich ob es nicht doch an den Rechten/Konfiguration des www Benutzers liegt? Viel bleibt nicht mehr übrig denke ich. Muss nochmal die PHP Konfiguration checken...

Sorry das ich so viel schwätze, aber vielleicht hilft das ja dem Nächsten:-)
 
Zurück
Oben